[TUHS] Charles Forsyth on putting Unix on a diet.

[TUHS] Charles Forsyth on putting Unix on a diet.

[Noel Chiappa]

    > From: Steve Nickolas

    > I personally believe a lot of code in modern operating systems is larger
    > than the task requires.

The "operating" is superfluous.

    Noel

[TUHS] Charles Forsyth on putting Unix on a diet.

[Clem Cole]

And to simplify that ...  s/operating systems/SW/


On Fri, Oct 27, 2017 at 6:36 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Steve Nickolas
>
>     > I personally believe a lot of code in modern operating systems is
> larger
>     > than the task requires.
>
> The "operating" is superfluous.
>
>     Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171027/b1a665ad/attachment.html>

[TUHS] Charles Forsyth on putting Unix on a diet.

[Steve Nickolas]

On Fri, 27 Oct 2017, Clem Cole wrote:

> And to simplify that ...  s/operating systems/SW/

Well, yeah.  Has M$ Word even really gotten much in the way of new 
features since version 6 in the early 1990s?  But it's sure gotten 
bigger... And that seems the way of software in general.

-uso.

[TUHS] Charles Forsyth on putting Unix on a diet.

[Andy Kosela]

On Friday, October 27, 2017, Steve Nickolas <usotsuki at buric.co> wrote:

> On Fri, 27 Oct 2017, Clem Cole wrote:
>
> And to simplify that ...  s/operating systems/SW/
>>
>
> Well, yeah.  Has M$ Word even really gotten much in the way of new
> features since version 6 in the early 1990s?  But it's sure gotten
> bigger... And that seems the way of software in general.
>
>
We don't even have to look at M$.  We can look at our own backyard and find
the same pattern.  UNIX in the 70s was small and simple, the same way Linux
kernel was small and simple in the early 90s.  Now it is a bloated,
fat monster.

It seems that it is very hard to avoid bloat in the software world in the
long run.  Most people don't care, but the original UNIX and C, Plan 9 and
Go projects could be one of the few I can think of that really cared about
minimalism.  It is interesting to note that they were built by the
very same group of people.

Minimalism is the main word here.  If you read personal website of Charles
Forsyth then you will notice he mentions it explicitly as his "overarching
theme".  That is the secret key to beauty and elegance in the software
world.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171027/8b8b51ef/attachment-0001.html>

[TUHS] Charles Forsyth on putting Unix on a diet.

[Larry McVoy]

On Fri, Oct 27, 2017 at 11:51:12PM +0200, Andy Kosela wrote:
> It seems that it is very hard to avoid bloat in the software world in the
> long run.  Most people don't care, but the original UNIX and C, Plan 9 and
> Go projects could be one of the few I can think of that really cared about
> minimalism.  

We cared.  We being the BitKeeper guys.  

BK as of 2002 (bk-2.0.5):
33 documented commands
wc *.c
  67633  225563 1565556 total

BK as of 15 years later (bk-7.3.2)
165 documented commands
wc *.c
 125812  444197 3017977 total

So we doubled in size for all the built in commands but we had 5x as many
commands.  A huge amount of functionality over the bk-2.x era.

The only way we did that was by encouraging and rewarding commits that took
out as much as they put in.

It's possible but you have to be disciplined.

--lm

[TUHS] Charles Forsyth on putting Unix on a diet.

[Steve Simon]

RE: minimalism

It was put to me that there is a big difference between
complicated and complex.

Complexity may be necessary to deal with difficult problems.
But the solution, built on the complex framework should never
be complicated.

Perhaps I am splitting semantic hairs but the description
appealed to me.

-Steve

[TUHS] Charles Forsyth on putting Unix on a diet.

[Tim Bradshaw]

> On 28 Oct 2017, at 00:15, Steve Simon <steve at quintile.net> wrote:
> 
> It was put to me that there is a big difference between
> complicated and complex.
> 
> Complexity may be necessary to deal with difficult problems.
> But the solution, built on the complex framework should never
> be complicated.

This is half-way (and perhaps more than that) to what the 'worse is better' paper would call 'the MIT approach'.  I think it's fairly obviously the right thing, and equally obviously almost never done.

--tim

[TUHS] Charles Forsyth on putting Unix on a diet.

[Bakul Shah]

On Fri, 27 Oct 2017 23:51:12 +0200 Andy Kosela <akosela at andykosela.com> wrote:
> We don't even have to look at M$.  We can look at our own backyard and find
> the same pattern.  UNIX in the 70s was small and simple, the same way Linux
> kernel was small and simple in the early 90s.  Now it is a bloated,
> fat monster.
> 
> It seems that it is very hard to avoid bloat in the software world in the
> long run.  Most people don't care, but the original UNIX and C, Plan 9 and
> Go projects could be one of the few I can think of that really cared about
> minimalism.  It is interesting to note that they were built by the
> very same group of people.
> 
> Minimalism is the main word here.  If you read personal website of Charles
> Forsyth then you will notice he mentions it explicitly as his "overarching
> theme".  That is the secret key to beauty and elegance in the software
> world.

Minimalism as a goal has been long lost in the Unix world.
(Well, everywhere but at least Unix started out lean). Even
the generic FreeBSD kernel is 20MB or so (txtsize).  When you
add in all the loadable kernel modules, it is about 52MB[1].
Linux is of course more bloated. Plan9 is quite lean but other
than a few diehard fans no one uses it. Worse, its leanness
lessons have not been learned by any other OS.

I wish there was a way to evolve plan9 into a modern Unix.
Making an existing modern Unix diet into a lean OS is close to
impossible.

A unix kernel boils down to a few subsystems: device drivers +
device switch, scheduling, VM, networking and network switch,
filesystems + filesystem switch, interrupt handling, process
management. Some graphics support. A bunch of this can be
pushed out of the kernel without much loss of efficiency.  And
may be the original design decisions of Unix need to be
revisited for 21st century hardware.

A comment on Charles Forsyth's paper. I saw most of his work
as essentially re-engineering (or perhaps just engineering).
This is actually pretty important and something we don't seem
to pay a lot of attention to. It is improving the fit and
finish of parts so that they fit well together. It is making
it easy to take things apart or put them together well.  It is
making diagnosis and repair easy.  Make reproducibiliy easy
etc. But we don't have a clear idea of what metrics to focus
on that will help this engineering.  Performance? Number of
lines of code?  Latency?  Energy used?  Maintainability?
Extensibility?  Curiously, what is most tangible to me not
what can be measured but a sense of aesthetics.

Bakul

[1] FreeBSD has some strange things: if_bxe.ko (for the Qlogic
10GBe card) is 2+ MB (larger than zfs.ko)! May be due to
proprietary binary blobs? The next after zfs is a driver for
another Qlogic card.

[TUHS] Charles Forsyth on putting Unix on a diet.

[Lyndon Nerenberg]

> I wish there was a way to evolve plan9 into a modern Unix.
> Making an existing modern Unix diet into a lean OS is close to
> impossible.

But if you try to turn Plan9 into a lean UNIX, you lose everything that Plan9 advocates.  In particular, I don't see how you can possibly integrate namespaces into UNIX in any meaningful way.  Without those, it's no longer Plan9, and therefore a pointless endeavour.

> A unix kernel boils down to a few subsystems: device drivers +
> device switch, scheduling, VM, networking and network switch,
> filesystems + filesystem switch, interrupt handling, process
> management. Some graphics support. A bunch of this can be
> pushed out of the kernel without much loss of efficiency.  And
> may be the original design decisions of Unix need to be
> revisited for 21st century hardware.

The release of the 10th Edition UNIX source is much more enlightening.  Here you can see a fully functional UNIX with what, 29?, system calls?  And you can see the genesis of many of the Plan9 concepts (/proc, dial(), mk, mux, etc).

--lyndon

[TUHS] Charles Forsyth on putting Unix on a diet.

[Lyndon Nerenberg]

> On Oct 27, 2017, at 7:34 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> 
> But if you try to turn Plan9 into a lean UNIX, you lose everything that Plan9 advocates.  In particular, I don't see how you can possibly integrate namespaces into UNIX in any meaningful way.  Without those, it's no longer Plan9, and therefore a pointless endeavour.

But as a thought experiment, I have long wondered how one might approach the UNIX kernel with the view of removing ioctl(2).  What would the aftermath look like?  That's probably the most invasive attack Plan9 could take on UNIX.  It would be very interesting to see what falls out.  It might be practical to attempt this with 10th Edition, just to see ...

--lyndon

[TUHS] Charles Forsyth on putting Unix on a diet.

[Bakul Shah]

On Fri, 27 Oct 2017 19:34:11 -0700 Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
Lyndon Nerenberg writes:
> > I wish there was a way to evolve plan9 into a modern Unix.
> > Making an existing modern Unix diet into a lean OS is close to
> > impossible.
> 
> But if you try to turn Plan9 into a lean UNIX, you lose everything that
> Plan9 advocates.  In particular, I don't see how you can possibly
> integrate namespaces into UNIX in any meaningful way.  Without those,
> it's no longer Plan9, and therefore a pointless endeavour.

As you may know I have been a 9fan for a long time & would
love if plan9 became mainstream. But I just don't see any hope
of a wider acceptance of Plan9.  My perception is that plan9
itself has not evolved a lot in 20-30 years. May be its
original structure is good enough or may be it just hasn't had
a large enough set of innovative users. The small group of
plan9 users continue to mostly use the stuff built by the Bell
lab guys.  I think it would be a real shame to see plan9
become a relic. The road not taken. Would be nice if we can do
something about it.

IMHO, the best hope to keep it alive is to pull a reverse C++
trick!  C++, which is now a much more complex beast of a PL,
initally got accepted because "it was compatible with C".  So
the idea here is to provide a Unix compatible (complex) API as
a library to allow running a lot of existing s/w and entice
people to write new s/w to a simpler but more composable API.

It won't make plan9 advocates happy and it won't have a
"plan9" API but this seems doable to me.  Start with the Plan9
kernel so you've already got process centric and mountable
namespaces. Next "port" linux or freebsd API. Write a set of
library functions that implement various Unix API calls by
calling on the plan9 API. Mutate the latter as necessary.  [As
an example, if 9P is found lacking, enhance it or replace it]
This is not unlike implementing linux API on top of a
microkernel. Concurrently port some kernel resident critical
subsystems from Unix to become user mode programs
communicating via 9p (or its child). All the while keeping an
eye on performance and complexity.

If done right, I think we can do away with containers & jails
for cloud based s/w, without any loss of security.o

So that is my pipe dream!

> > A unix kernel boils down to a few subsystems: device drivers +
> > device switch, scheduling, VM, networking and network switch,
> > filesystems + filesystem switch, interrupt handling, process
> > management. Some graphics support. A bunch of this can be
> > pushed out of the kernel without much loss of efficiency.  And
> > may be the original design decisions of Unix need to be
> > revisited for 21st century hardware.
> 
> The release of the 10th Edition UNIX source is much more enlightening. 
> Here you can see a fully functional UNIX with what, 29?, system calls? 
> And you can see the genesis of many of the Plan9 concepts (/proc,
> dial(), mk, mux, etc).

I don't know much about it.

In a separate message you wrote:

> But as a thought experiment, I have long wondered how one might approach
> the UNIX kernel with the view of removing ioctl(2).  What would the
> aftermath look like?  That's probably the most invasive attack Plan9
> could take on UNIX.  It would be very interesting to see what falls out.
>  It might be practical to attempt this with 10th Edition, just to see
> ...

That is the "dieting" approach. Much harder as you have to
constantly watch out you haven't broken anything.  But if you
start with plan9, ioctl() is already gone! However, it can be
implemented as a library function for dusty decks.

[TUHS] Charles Forsyth on putting Unix on a diet.

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On Fri, 27 Oct 2017, Clem Cole wrote:

> And to simplify that ...  s/operating systems/SW/

Not to mention HW...  I know how a POTS telephone works, but a cellular? 
Only vaguely...  Ditto B/W television vs. colour.  And I stopped 
maintaining my own cars years ago; about the onpy thing I recognise under 
the bonnet these days is the engine.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Charles Forsyth on putting Unix on a diet.

[Norman Wilson]

Chris Torek:

  You're not perpendicular to your own surface?  :-)

===

I'm not as limber as I used to be.

Besides, I'm left-handed, so what use would I have for
right angles?

Norman Wilson
Toronto ON
(I don't wish to know that)

[TUHS] Charles Forsyth on putting Unix on a diet.

[Norman Wilson]

George Michaelson:

  wish I hadn't read "Norman Wilson" as "Norman Wisdom" (british
  prat-fall comedian in the style of Jerry Lewis)

===

It's much better than the more-common typo in which
people call me normal.  Neither accurate nor an
aspiration.

Norman Wilson
Toronto ON

[TUHS] Charles Forsyth on putting Unix on a diet.

[Chris Torek]

>It's much better than the more-common typo in which
>people call me normal.  Neither accurate nor an
>aspiration.

You're not perpendicular to your own surface?  :-)

Chris

[TUHS] Charles Forsyth on putting Unix on a diet.

[Doug McIlroy]

As an admirer of minimalism, who has given talks that extol
Norman Wilson's streamlining of research Unix, I naturally
like Forsythe's thesis.

I noticed unintended irony in one more or less throw-away remark:
"It is dangerous to place too much hope in any improvement coming from just
following new fashions, if we lack insight into what really went wrong
before. Without that insight, I suspect that rewriting UNIX in C++,
for example, could easily become an excuse for increasing complexity
(because by using C++ `we can handle more complexity')."

Bjarne Stroustrup's avowed reason for building cfront, which 
evolved into C++, was to have a tool for building an operating
system in object-oriented style. The tool took on a life of
its own, and arguably became more complex than the old-fashioned
Unix he aspired to improve on.

Doug

[TUHS] Charles Forsyth on putting Unix on a diet.

[George Michaelson]

wish I hadn't read "Norman Wilson" as "Norman Wisdom" (british
prat-fall comedian in the style of Jerry Lewis)

On Fri, Oct 27, 2017 at 12:57 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> As an admirer of minimalism, who has given talks that extol
> Norman Wilson's streamlining of research Unix, I naturally
> like Forsythe's thesis.

[TUHS] Charles Forsyth on putting Unix on a diet.

[Dan Cross]

I've always enjoyed this paper; recently I found occasion to thumb
through it again. I thought I'd pass it on; I'm curious what some on
the list think about this given their first-hand knowledge of relevant
history (Larry, I'm looking at you; especially with respect his
comments on the VM system).

        - Dan C.

http://www.terzarima.net/doc/taste.pdf

[TUHS] Charles Forsyth on putting Unix on a diet.

[Larry McVoy]

I'm in the middle of a family medical thing, I glanced it this, it looks
like it has merit.  Give me some time, if I'm the Larry you meant, maybe
I'm yapping and I have no place to be talking.  I'll give it a read either
way, I love stuff like this.

On Tue, Oct 24, 2017 at 10:51:17PM -0400, Dan Cross wrote:
> I've always enjoyed this paper; recently I found occasion to thumb
> through it again. I thought I'd pass it on; I'm curious what some on
> the list think about this given their first-hand knowledge of relevant
> history (Larry, I'm looking at you; especially with respect his
> comments on the VM system).
> 
>         - Dan C.
> 
> http://www.terzarima.net/doc/taste.pdf

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Charles Forsyth on putting Unix on a diet.

[Larry McVoy]

On Tue, Oct 24, 2017 at 10:51:17PM -0400, Dan Cross wrote:
> I've always enjoyed this paper; recently I found occasion to thumb
> through it again. I thought I'd pass it on; I'm curious what some on
> the list think about this given their first-hand knowledge of relevant
> history (Larry, I'm looking at you; especially with respect his
> comments on the VM system).
> 
>         - Dan C.
> 
> http://www.terzarima.net/doc/taste.pdf

OK, I've read it.  This could have been a great paper if he had included
some performance results.  As it is, I'm sorry that his ideas didn't take
hold, or at least get some discussion.

The paging stuff is neat but it doesn't address the file system page cache
so far as I tell.  It's process based so unless the process had the file
mmap-ed it wouldn't take care of it.  And mmap didn't exist at the time,
so I'm not sure how he handed the page cache.  

He was fixated on code size, and yeah, on 4MB machines, you need to
be even on 8 you need to be (at Sun we called EMACS Eight Megs And
Constantly Swapping).  But I'd like to know if his paging scheme worked.
I went through a period where I wrote over a dozen different pageout
daemons in an effort to do a better job; none did.  They had certain
use cases where they did better but then other work loads made them
perform worse.  That global pageout daemon is still around, it's
depressingly hard to do better than that.  If he succeeded it would
be nice to have numbers.

His pageout scheme could have all forward pointers if he had them in
the vnode along with the process.

I agree with him on fork, there is no reason not do do vfork in fork
that I can think of (other than wnj's hack of putting stats in the 
parent process by the child in csh and that was just gross).

His comments on the file system switch vs VFS sort of miss the point
that the VFS was put in place to allow file systems that don't have
Unix semantics (NFS being the biggest example).  But I agree that 
there perhaps could have been a better approach, this is why it 
would have been nice to have his stuff get a broader audience.

I disagree on the streams/STREAMS stuff, that shit has no place in
anything that wants performance.  I'm working with netflix, trying
to do better than this:

https://news.ycombinator.com/item?id=15367421

which is a discussion of their writeup of how they managed to push
~100Gbit/sec of movies on a single machine.  Sticking STREAMS in the
middle of that was a bad idea back in the day and a worse idea today.

But all in all, an interesting paper.  It's pretty amazing how many of
the people in the references I know, lots of them I've worked with, Steve
Kleiman was my mentor at Sun, Rosenthal and I had tons of OS discussions.
I toyed with going to HP Labs to work with John Wilkes, etc.  Definitely
a trip down memory lane and makes me feel super lucky to have gotten to
work with people of that caliber.

Thanks for the pointer.

--lm

[TUHS] Charles Forsyth on putting Unix on a diet.

[George Michaelson]

I worked with Charles in the University of York. he's the guy who said
to me "how can it be simple, if the printout is half an inch thick"
about SMTP.

Charles also enjoyed himself: fancy dress, he had a full on Sun-King
court suit made, to go with his huge head of hair. This, in york, a
city of red-brick terraced houses, back-to-backs, and beer. Louis XIV
walking down t' road for a pint...

I think when he implemented streams in one or two pages of text from
the BLTJ article, and then sighed at the size of STREAMS when it came
to life.. says it all.  he was very very strong on a reductionist
'size matters' world view. His editor of choice in 1984 was ed, with a
command macro to repaint -22 + 22 about the . line.

(I hasten to add, Charles and I worked in totally different areas, and
I use the term "worked" in regards to myself with some trepidation)

On Fri, Oct 27, 2017 at 3:27 AM, Larry McVoy <lm at mcvoy.com> wrote:
> On Tue, Oct 24, 2017 at 10:51:17PM -0400, Dan Cross wrote:
>> I've always enjoyed this paper; recently I found occasion to thumb
>> through it again. I thought I'd pass it on; I'm curious what some on
>> the list think about this given their first-hand knowledge of relevant
>> history (Larry, I'm looking at you; especially with respect his
>> comments on the VM system).
>>
>>         - Dan C.
>>
>> http://www.terzarima.net/doc/taste.pdf
>
> OK, I've read it.  This could have been a great paper if he had included
> some performance results.  As it is, I'm sorry that his ideas didn't take
> hold, or at least get some discussion.
>
> The paging stuff is neat but it doesn't address the file system page cache
> so far as I tell.  It's process based so unless the process had the file
> mmap-ed it wouldn't take care of it.  And mmap didn't exist at the time,
> so I'm not sure how he handed the page cache.
>
> He was fixated on code size, and yeah, on 4MB machines, you need to
> be even on 8 you need to be (at Sun we called EMACS Eight Megs And
> Constantly Swapping).  But I'd like to know if his paging scheme worked.
> I went through a period where I wrote over a dozen different pageout
> daemons in an effort to do a better job; none did.  They had certain
> use cases where they did better but then other work loads made them
> perform worse.  That global pageout daemon is still around, it's
> depressingly hard to do better than that.  If he succeeded it would
> be nice to have numbers.
>
> His pageout scheme could have all forward pointers if he had them in
> the vnode along with the process.
>
> I agree with him on fork, there is no reason not do do vfork in fork
> that I can think of (other than wnj's hack of putting stats in the
> parent process by the child in csh and that was just gross).
>
> His comments on the file system switch vs VFS sort of miss the point
> that the VFS was put in place to allow file systems that don't have
> Unix semantics (NFS being the biggest example).  But I agree that
> there perhaps could have been a better approach, this is why it
> would have been nice to have his stuff get a broader audience.
>
> I disagree on the streams/STREAMS stuff, that shit has no place in
> anything that wants performance.  I'm working with netflix, trying
> to do better than this:
>
> https://news.ycombinator.com/item?id=15367421
>
> which is a discussion of their writeup of how they managed to push
> ~100Gbit/sec of movies on a single machine.  Sticking STREAMS in the
> middle of that was a bad idea back in the day and a worse idea today.
>
> But all in all, an interesting paper.  It's pretty amazing how many of
> the people in the references I know, lots of them I've worked with, Steve
> Kleiman was my mentor at Sun, Rosenthal and I had tons of OS discussions.
> I toyed with going to HP Labs to work with John Wilkes, etc.  Definitely
> a trip down memory lane and makes me feel super lucky to have gotten to
> work with people of that caliber.
>
> Thanks for the pointer.
>
> --lm

[TUHS] Charles Forsyth on putting Unix on a diet.

[Steve Nickolas]

On Fri, 27 Oct 2017, George Michaelson wrote:

> I worked with Charles in the University of York. he's the guy who said
> to me "how can it be simple, if the printout is half an inch thick"
> about SMTP.
>
> Charles also enjoyed himself: fancy dress, he had a full on Sun-King
> court suit made, to go with his huge head of hair. This, in york, a
> city of red-brick terraced houses, back-to-backs, and beer. Louis XIV
> walking down t' road for a pint...

This is that guy who did the clone of the v7 Bourne shell that used to be 
used in Minix and PicoBSD and was the basis of pdksh?

(There was, actually, a Korn shell clone for MS-DOS and OS/2 based on it.)

> I think when he implemented streams in one or two pages of text from
> the BLTJ article, and then sighed at the size of STREAMS when it came
> to life.. says it all.  he was very very strong on a reductionist
> 'size matters' world view. His editor of choice in 1984 was ed, with a
> command macro to repaint -22 + 22 about the . line.

I personally believe a lot of code in modern operating systems is larger 
than the task requires.

-uso.

[TUHS] Charles Forsyth on putting Unix on a diet.

[arnold]

Steve Nickolas <usotsuki at buric.co> wrote:

> On Fri, 27 Oct 2017, George Michaelson wrote:
>
> > I worked with Charles in the University of York. he's the guy who said
> > to me "how can it be simple, if the printout is half an inch thick"
> > about SMTP.
> >
> > ....
>
> This is that guy who did the clone of the v7 Bourne shell that used to be 
> used in Minix and PicoBSD and was the basis of pdksh?

Yes.

Charles is still very active in the Plan 9 world. I don't know if he
still prefers ed over sam or Acme though. :-)

Arnold

[TUHS] Charles Forsyth on putting Unix on a diet.

[Derek Fawcus]

On Thu, Oct 26, 2017 at 10:27:35AM -0700, Larry McVoy wrote:
> > http://www.terzarima.net/doc/taste.pdf
> 
> OK, I've read it.  This could have been a great paper if he had included
> some performance results.

Well, once could always ask him if he still has such; since he tends to hang
out on the 9fans list.  I believe his address may be charles.forsyth at gmail.com,
(but I don't have a recent message to verify against).

DF

[TUHS] Charles Forsyth on putting Unix on a diet.

[David Arnold]

He last posted from that address on 18th October. 



d

> On 27 Oct 2017, at 18:30, Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
> 
> On Thu, Oct 26, 2017 at 10:27:35AM -0700, Larry McVoy wrote:
>>> http://www.terzarima.net/doc/taste.pdf
>> 
>> OK, I've read it.  This could have been a great paper if he had included
>> some performance results.
> 
> Well, once could always ask him if he still has such; since he tends to hang
> out on the 9fans list.  I believe his address may be charles.forsyth at gmail.com,
> (but I don't have a recent message to verify against).
> 
> DF