[TUHS] Anyone ever heard of teaching a case study of Initial Unix?

[TUHS] Anyone ever heard of teaching a case study of Initial Unix?

[sjenkin]

I’ve never heard of a Computer Science or Software Engineering program
that included a ‘case study’ component, especially for Software Development & Projects.

MBA programs feature an emphasis on real-world ‘case studies’, to learn from successes & failures,
to give students the possibility of not falling into the same traps. 

Creating Unix V6, because it profoundly changed computing & development,
would seem an obvious Case Study for many aspects of Software, Coding and Projects.

There have been many descriptive treatments of Initial Unix,
but I’ve never seen a Case Study, 
with explicit lessons drawn, possibly leading to metrics to evaluate Project progress & the coding process.

Developers of Initial Unix arguably were 10x-100x more productive than IBM OS/360, a ‘best practice’ development at the time,
so what CSRC did differently is worth close examination.

I’ve not seen examined the role of the ‘capability’ of individual contributors, the collaborative, collegiate work environment 
and the ‘context’, a well funded organisation not dictating deadlines or product specifications for researchers.

USG, then USL,  worked under ’normal commercial’ management pressure for deadlines, features and specifications.

The CSRC/1127 group did have an explicit approach & principles for what they did and how they worked,
publishing a number of books & papers on them - nothing they thought or did is secret or unavailable for study.

Unix & Unix tools were deliberately built with explicit principles, such as “Less is More”.
Plan 9 was also built on explicit Design principles.

The two most relevant lessons I draw from Initial Unix are:

	- the same as Royce's original “Software Waterfall” paper, 
		“build one to throwaway” [ albeit, many, many iterations of the kernel & other code ]

	- Writing Software is part Research, part Creative ‘Art’:
		It’s Done when it's Done, invention & creation can’t be timetabled.

For the most reliable, widely used Open Source projects,
the “Done when it’s Done” principle is universally demonstrated.

I’ve never seen a large Open Source project succeed when attempting to use modern “Project Management” techniques.

These Initial Unix lessons, if correct and substantiated, should cause a revolution in the teaching & practice
of Professional Programming, i.e. Programming In the Large, for both CS & SW.

There are inherent contradictions within the currently taught Software Project Management Methodologies:

	- Individual capability & ability is irrelevant
		The assumption is ‘programmers’ are fungible/ identical units - all equally able to solve any problem.
		Clearly incorrect: course evaluations / tests demonstrate at least a 100x variance in ability in every software dimension.

	- Team environment, rewards & penalties and corporate context are irrelevant,
		Perverse incentives are widely evident, the cause of many, or all, “Death Marches”.

	- The “Discovery & Research Phases” of a project are timetabled, an impossibility.

Any suggestions for Case Studies gratefully accepted.

===========

Professions & Professionals must learn over time:

	 there’s a negative aspect (don’t do this) and positive aspect (do this) for this deliberate learning & improvement.

Negatives are “Don’t Repeat, or Allow, Known Errors, Faults & Failures” 
plus in the Time Dimension, “Avoid Delays, Omissions and Inaction”.

Positives are what’s taught in Case Studies in MBA courses: 

	use techniques & approaches known to work.

Early Unix, from inception to CACM papers, 1969 to 1974, took probably 30 man-years,
and produced a robust, performant and usable system for it’s design target, “Software Development”.

This in direct comparison to Fred Brooks IBM OS/360 effort around 5 years before that consumed 3,000-4,000 man-years
was known for bugs, poor & inconsistent code quality, needed large resource to run and was, politely, non-performant.

This was a commercial O/S, built by a capable, experienced engineering organisation, betting their company on it,
who assigned their very best to the hardware & software projects. It was “Best of Breed” then, possibly also now.

MULTICS had multiple business partners, without the same, single focus or commercial imperative.
I don’t believe it’s comparable to either system.

Initial Unix wasn’t just edit, compile & run, but filesystems, libraries, debugging & profiling tools, language & compiler construction tools, ‘man’ pages, document prep (nroff/troff) and 'a thousand' general tools leveraging shell / pipe.

This led directly to modern toolchains, config, make & build systems, Version Control, packaging systems, and more.
Nothing of note is built without using descendants or derivatives of these early toolchains.

All this is wrapped around by many Standards, necessary for portable systems, even based on the same platform, kernel and base system.

The “Tower of Babel” problem is still significant & insurmountable at times, even in C-C & Linux-Linux migration, 
but without POSIX/IEEE standards the “Software Tarpit” and "Desert of Despair” would’ve been unsolvable.

The early Unix system proved adaptable and extensible to many other environments, well beyond “Software Development”.

===========

[ waterfall model ]

Managing the development of large software systems: concepts and techniques
W. W. Royce, 1970 [ free access ]
	<https://dl.acm.org/doi/10.5555/41765.41801>

	STEP3: DO IT TWICE, pg 334

	After documentation, the second most important criterion for success revolves around whether the product is totally original.
	If the computer program in question is being developed for the first time, 
	arrange matters so that the version finally delivered to the customer for operational deployment 
	is actually the second version insofar as critical design/operations areas are concerned.

===========

Plan 9, Design

<https://9p.io/sys/doc/9.html>

The view of the system is built upon three principles. 
	First, resources are named and accessed like files in a hierarchical file system.
	Second, there is a standard protocol, called 9P, for accessing these resources. 
	Third, the disjoint hierarchies provided by different services are joined together into a single private hierarchical file name space. 

The unusual properties of Plan 9 stem from the consistent, aggressive application of these principles.

===========

Escaping the software tar pit: model clashes and how to avoid them
Barry Boehm, 1999 [ free access ]
	<https://dl.acm.org/doi/abs/10.1145/308769.308775#>

===========

Mythical Man-Month, The: Essays on Software Engineering, 
Anniversary Edition, 2nd Edition
Fred Brooks

Chapter 1. The Tar Pit

Large-system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it.

===========
--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Al Kossow]

On 7/2/24 9:51 PM, sjenkin@canb.auug.org.au wrote:

> I’ve never seen a large Open Source project succeed when attempting to use modern “Project Management” techniques.
> 

Managing an open source project is like herding a pack of alpha male tomcats with their own agendas that you can't fire.

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[arnold]

Al Kossow <aek@bitsavers.org> wrote:

> On 7/2/24 9:51 PM, sjenkin@canb.auug.org.au wrote:
>
> > I’ve never seen a large Open Source project succeed when attempting to use modern “Project Management” techniques.
> > 
>
> Managing an open source project is like herding a pack of alpha male tomcats with their own agendas that you can't fire.
>
>

I think this is true only of the large projects. As Clem has argued,
when there's a single strong leader, it's different (Linus, Guido van
Rossum, bash and gawk are such examples).

Arnold

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Clem Cole]

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

On Wed, Jul 3, 2024 at 1:02 AM Al Kossow <aek@bitsavers.org> wrote:

>
>
> Managing an open source project is like herding a pack of alpha male
> tomcats with their own agendas that you can't fire.
>
*i.e., *the Cathedral (*vs.* the bazaar) with a small group of people, like
original, UNIX and Plan9 projects works better.

Small is beautiful, particularly in a development team, but the
principles of throwing one away and "*it is done when it is done*" have to
be considered.  FWIW: In the HW world, Seymour Cray said that the best HW
development team has about 10-12 people and no more.  Maybe there is
someone who knows about real-world complex systems that can still be
understood by a small number of designers.

Of course, the problem today is that the systems are a few orders of
magnitude more complex.  There is no way a single human can comprehend
every transistor in a modern processor, as Seymour did in the CDC and later
Cray machines. The same is true for operating systems environments -
although I think the >>kernel< can be, particularly if it's something more
like Per Brinch Hansen's idea of a 'nucleus,' which I think you can argue
is what Plan9 was and Unix V0-6 were pretty close to being.

@steve jenkin <sjenkin@canb.auug.org.au> FWIW: It also depends on how you
measure "success."   Both the original and derivatives of Linux and OS/360
can be considered "success" if you look at how they are used and their
impact, particularly in a commercial setting.  But in many ways, neither
had (nor has had) an impact as the core *UNIX ideas* have on the
industry/CS community at large.  There was really little that was "new" in
either OS/360 or Linux.  Both were based on keeping SW developed for older
systems working and offering new *attributes* (like not being AT&T
copyright) and, eventually (later) some new features.

Compare the fact that were not really novel with Plan9.  While moving from
an application from UNIX to Plan9 was possible, the designers decidedly
broke from the past - such as making a uniform namespace and using 9P as
the "glue layer." It turns out 9P could do many of the things that original
UNIX layers could, so moving from a UNIX system was not a huge lift, but
(as I understand it - Rob, please correct me if I have misinterpreted), it
was not a goal to allow UNIX programs to be rebuilt with make(1) [or mk(1)]
with no changes.

That can not be said for OS/360 or Linux.  In fact, if the programmer had
followed Henry's 10 Programmers' Commandments, you could type: make and
most programs coming from your vax or 68000 UNIX box - "just worked."
 Brooks and team considered it a requirement that older applications "just
work" - which, in fact, was one of the reasons why, even though at the
inception of the project, S/360 was designed to be IBM's first ASCII system
[remember IBM and AT&T were the two primary sponsors of ASCII to ASA and
IBM person chaired the committee]. EBCDIC was created so that those old
codes could be supported and ended up being the path of least resistance
when OS/360 was late.

My point is that the cats appear after the fact. It is challenging to
direct them towards your goals, not theirs. Thus, the 'benevolent dictator'
model seems to appear in "successful" FOSS projects. I would argue with ers
that this is actually the same Cathredal with a master builder making the
choices, BTW.

Clem

ᐧ

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Theodore Ts'o]

On Wed, Jul 03, 2024 at 10:04:58AM -0400, Clem Cole wrote:
> On Wed, Jul 3, 2024 at 1:02 AM Al Kossow <aek@bitsavers.org> wrote:
> > Managing an open source project is like herding a pack of alpha male
> > tomcats with their own agendas that you can't fire.
> >
> *i.e., *the Cathedral (*vs.* the bazaar) with a small group of people, like
> original, UNIX and Plan9 projects works better.
> 
> Small is beautiful, particularly in a development team, but the
> principles of throwing one away and "*it is done when it is done*" have to
> be considered.

This.  It's more about the scope of the project.  I had a work project
(a new form of SMR disks where you can dynamically convert regions of
disk platters from CMR to SMR non-destructively with respect to the
region of the disk not being converted) where I was herding cats from
multiple different product areas (departments): hardware platforms,
software infrastructure, software reliability engineers) reporting to
different VP's with different departmental OKR's for which they get
their performance reviews.

I also had to wrangle two different HDD manufacturer partners, and a
T.13 standards subcommittee, and my skills trying to hold together a
team where I had no management authority, nor a VP to glower
threateningly behind me, stood me in very good stead.  Fortunately
leadership stints that I had in the open source world, the IETF,
USENIX, and the Episcopal Diocese of Massachusetts meant that this
weasn't the first time to do this kind of cat herding.

Small might be beautiful, but this project reduced storage TCO costs
by vast amounts of money, so my company thought it was really pretty.  :-)

> My point is that the cats appear after the fact. It is challenging to
> direct them towards your goals, not theirs. Thus, the 'benevolent dictator'
> model seems to appear in "successful" FOSS projects. I would argue with ers
> that this is actually the same Cathredal with a master builder making the
> choices, BTW.

In essentially all volunteer projects, a leader's only real power is
to say "no".  They can't force anyone to do anything that they want,
but instead have to rely on their skills of pursuation.  This is true
if you are an open source leader, or if you are an IETF Area Director.
In the case of a non-profit which has money, such as (for example)
Usenix or the Episcopal Diocese of Massachusetts, or the Linux
Foundation, you might have some ability to issue commands to the
staff.  But the vast majority of the work of these non-profits rely on
volunteers, and so again, you have to be able to pursuade those
volunteers community to follow you when you say, "let's go thataway".

The organizations which are lucky enough to have such servant leaders
will tend to prosper.  OTOH, open source projects which spend huge
amounts of time fighting over who has CVS commit access, leading to
factions of developers to fork off to form rival projects, will tend
to be less successful.  There are lots of people who will complain
about Linus Torvalds' supposed lack of social skills; but his ability
to hold the senior members of the development community together
without having the sorts of splits that we saw in FreeBSD, NetBSD,
OpenBSD, DragonflyBSD, etc., should be a hint that the story is a bit
more complicated than what is promulgated by the click-baity headlines
out there.

	      	       		   	     - Ted
						     

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Larry McVoy]

On Wed, Jul 03, 2024 at 11:22:14AM -0400, Theodore Ts'o wrote:
> There are lots of people who will complain
> about Linus Torvalds' supposed lack of social skills; but his ability
> to hold the senior members of the development community together
> without having the sorts of splits that we saw in FreeBSD, NetBSD,
> OpenBSD, DragonflyBSD, etc., should be a hint that the story is a bit
> more complicated than what is promulgated by the click-baity headlines
> out there.

This.  I recognized this in Linus decades ago and it's why I switched to
Linux.  I was a BSD (aka SunOS) guy big time and I left that because
of what I saw in Linus.  I miss BSD a little but am quite happy with
Linux.  Say what you will about his rough edges, he's held it together
for a long time.  Kudos.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Marc Rochkind]

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

Steve Jenkin suggests: "Developers of Initial Unix arguably were 10x-100x
more productive than IBM OS/360..."

Indeed, this is part of accepted UNIX lore. However, to me, "productivity"
in this context is a measure of how much time it takes to implement a
specified objective. UNIX did not have a specified objective. From "The
UNIX Time Sharing System," (Ritchie & Thompson):

"Perhaps paradoxically, the success of UNIX is largely due to the fact that
it was not designed to meet any predefined objectives."

So, does this productivity advantage really mean anything? It's comparing a
research project to an industrial development.

The UNIX development methodology would seem to be this: Get a very small
number of top people together with a common vision, ideally fewer than
three, and see what happens. However many mistakes were made on the OS/360
project (very completely documented by Brooks), the need for an OS for the
emerging 360 series would probably not have been met by the "see what
happens" approach.

Marc

On Wed, Jul 3, 2024 at 12:27 AM Al Kossow <aek@bitsavers.org> wrote:

> On 7/2/24 9:51 PM, sjenkin@canb.auug.org.au wrote:
>
> > I’ve never seen a large Open Source project succeed when attempting to
> use modern “Project Management” techniques.
> >
>
> Managing an open source project is like herding a pack of alpha male
> tomcats with their own agendas that you can't fire.
>
>
>

-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[G. Branden Robinson]

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

At 2024-07-03T08:59:11-0600, Marc Rochkind wrote:
> Steve Jenkin suggests: "Developers of Initial Unix arguably were
> 10x-100x more productive than IBM OS/360..."
> 
> Indeed, this is part of accepted UNIX lore.

That claim reminds me of a more general one.  Applied to software
development writ large, it seems to be lore, not a reproducible
scientific result.

I refer of course to Sackman, Erickson, and Grant's 1968 CACM paper
which documented a DARPA experiment that found a productivity range of
28:1 in their sample of programmers (with veterans of 7 years'
experience pitted against "trainees").  Naturally enough, plenty of
people who make claims about variance in programmer productivity are
unaware of this paper's existence; it's not actually relevant to them as
a source of knowledge.

https://web.archive.org/web/20120204023412/http://dustyvolumes.com/archives/497

Thomas Dickey, better known today as the maintainer of ncurses, xterm,
lynx, and mawk (all for 30 years or more, and among other projects),
published a critique of this study in 1981.

https://web.archive.org/web/20120204023555/http://dustyvolumes.com/archives/498

Bill Curtis published a critique of the Sackler et al. paper in 1988.

I quote (via Dickey):

"Sackman's ... message that substantial performance differences do exist
among programmers remains valid.  Detecting a 20+:1 range ratio depends
upon having one brilliant and one horrid performance in a sample.
However the range ratio is not a particularly stable measure of
performance variability among programmers.  The dispersions of such data
as appear in Table I are better represented by such measures as the
standard deviation or semiinterquartile range."

https://invisible-island.net/personal/paperstuff.html

We have likely all observed how this 28:1 ratio has bloated in retelling
over time, like the length of a fish catch, to 100:1 or even 1000:1.
Similarly we're all familiar with the common practice of presenting the
mean and sometimes the range of some data sample to support one's
argument, without mentioning the median or mode, let alone the variance
(or the standard deviation).  (If a member of one's audience is familiar
with non-Gaussian distributions and inquires whether one's sample may be
better characterized by one, you invite them to disengage from the
discussion.)

I assert that this "productivity gap" is a myth, and that it persists
because it serves the purposes of diverse audiences who adopt it with
motivated reasoning.

1.  Immature Unix enthusiasts like to reassure themselves, and others
    nearby, of their inherent superiority to rival programmers.

2.  Managers like to contrive reasons for (not) promoting individual
    contributors.  It's easy to cite this productivity "statistic" and
    then suggest, without indicating anything concrete, that an employee
    is either a rock star or a mediocrity.

3.  Directors in organizations like not having to further justify a
    "stack-rank and cut" approach to reducing salary and benefits as a
    proportion of operational expenditures.

    https://en.wikipedia.org/wiki/Vitality_curve

4.  Business culture in general is deeply wedded to the idea that
    individual productivity, merit, or capacity for "wealth creation" is
    variable by several orders of magnitude, because this claim
    "justifies" variance in compensation over a similarly large range,
    even among college-educated professionals in an organization,
    setting aside those members of staff whose collars shade more toward
    blue.  (Outsourcing is useful in increasing opacity, segregating
    workers, and setting them up to have conflicting interests.)

    If people start applying their capacity for critical thought to the
    proposition that the CEO is 40,000 times more productive than a
    "Software Engineer II", nothing good will happen.

_Is_ "productivity" among programmers, however defined and measured,
nonuniform?  Likely yes.  Has our industry studied the question in a
serious way, applying rigorous experimental design and statistical
analysis?  Perhaps not.

And if we did, would any of the people making this claim read or
comprehend the research if it didn't support their biases?

You already know the answer.

We utter myths about falsifiable propositions not because we care about
their truth values, but precisely because we don't.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Marc Donner]

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

Back in the mid-to-late 1980s I was the ringleader of the UNIX underground
at IBM Research.  Interestingly, we were for a couple of years the largest
non-academic customer for Sun Microsystems on the east coast of the US.

When IBM bought ROLM, a maker of telephone equipment, they were confronted
with ROLM's insistence on using Sun equipment (and UNIX in general) for
their software development.

So a stream of IBM executives made their way to my office in Yorktown
Heights to try to figure out whether this demand was for real.

I would show them my development environment (emacs and make plus a bunch
of ancillary tools) and demonstrate how I could edit code, build, test, and
debug quickly and smoothly.

After half a dozen VPs came through, they agreed and placed a large order
with Sun for ROLM.  That might have helped the business case for a better
AIX, but I'm not sure.
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>


On Wed, Jul 3, 2024 at 7:35 PM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> At 2024-07-03T08:59:11-0600, Marc Rochkind wrote:
> > Steve Jenkin suggests: "Developers of Initial Unix arguably were
> > 10x-100x more productive than IBM OS/360..."
> >
> > Indeed, this is part of accepted UNIX lore.
>
> That claim reminds me of a more general one.  Applied to software
> development writ large, it seems to be lore, not a reproducible
> scientific result.
>
> I refer of course to Sackman, Erickson, and Grant's 1968 CACM paper
> which documented a DARPA experiment that found a productivity range of
> 28:1 in their sample of programmers (with veterans of 7 years'
> experience pitted against "trainees").  Naturally enough, plenty of
> people who make claims about variance in programmer productivity are
> unaware of this paper's existence; it's not actually relevant to them as
> a source of knowledge.
>
>
> https://web.archive.org/web/20120204023412/http://dustyvolumes.com/archives/497
>
> Thomas Dickey, better known today as the maintainer of ncurses, xterm,
> lynx, and mawk (all for 30 years or more, and among other projects),
> published a critique of this study in 1981.
>
>
> https://web.archive.org/web/20120204023555/http://dustyvolumes.com/archives/498
>
> Bill Curtis published a critique of the Sackler et al. paper in 1988.
>
> I quote (via Dickey):
>
> "Sackman's ... message that substantial performance differences do exist
> among programmers remains valid.  Detecting a 20+:1 range ratio depends
> upon having one brilliant and one horrid performance in a sample.
> However the range ratio is not a particularly stable measure of
> performance variability among programmers.  The dispersions of such data
> as appear in Table I are better represented by such measures as the
> standard deviation or semiinterquartile range."
>
> https://invisible-island.net/personal/paperstuff.html
>
> We have likely all observed how this 28:1 ratio has bloated in retelling
> over time, like the length of a fish catch, to 100:1 or even 1000:1.
> Similarly we're all familiar with the common practice of presenting the
> mean and sometimes the range of some data sample to support one's
> argument, without mentioning the median or mode, let alone the variance
> (or the standard deviation).  (If a member of one's audience is familiar
> with non-Gaussian distributions and inquires whether one's sample may be
> better characterized by one, you invite them to disengage from the
> discussion.)
>
> I assert that this "productivity gap" is a myth, and that it persists
> because it serves the purposes of diverse audiences who adopt it with
> motivated reasoning.
>
> 1.  Immature Unix enthusiasts like to reassure themselves, and others
>     nearby, of their inherent superiority to rival programmers.
>
> 2.  Managers like to contrive reasons for (not) promoting individual
>     contributors.  It's easy to cite this productivity "statistic" and
>     then suggest, without indicating anything concrete, that an employee
>     is either a rock star or a mediocrity.
>
> 3.  Directors in organizations like not having to further justify a
>     "stack-rank and cut" approach to reducing salary and benefits as a
>     proportion of operational expenditures.
>
>     https://en.wikipedia.org/wiki/Vitality_curve
>
> 4.  Business culture in general is deeply wedded to the idea that
>     individual productivity, merit, or capacity for "wealth creation" is
>     variable by several orders of magnitude, because this claim
>     "justifies" variance in compensation over a similarly large range,
>     even among college-educated professionals in an organization,
>     setting aside those members of staff whose collars shade more toward
>     blue.  (Outsourcing is useful in increasing opacity, segregating
>     workers, and setting them up to have conflicting interests.)
>
>     If people start applying their capacity for critical thought to the
>     proposition that the CEO is 40,000 times more productive than a
>     "Software Engineer II", nothing good will happen.
>
> _Is_ "productivity" among programmers, however defined and measured,
> nonuniform?  Likely yes.  Has our industry studied the question in a
> serious way, applying rigorous experimental design and statistical
> analysis?  Perhaps not.
>
> And if we did, would any of the people making this claim read or
> comprehend the research if it didn't support their biases?
>
> You already know the answer.
>
> We utter myths about falsifiable propositions not because we care about
> their truth values, but precisely because we don't.
>
> Regards,
> Branden
>

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[A. P. Garcia]

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

On Wed, Jul 3, 2024, 1:17 AM <sjenkin@canb.auug.org.au> wrote:

> I’ve never heard of a Computer Science or Software Engineering program
> that included a ‘case study’ component, especially for Software
> Development & Projects.
>
> <snip>
>
> Developers of Initial Unix arguably were 10x-100x more productive than IBM
> OS/360, a ‘best practice’ development at the time,
> so what CSRC did differently is worth close examination.
>
> I’ve not seen examined the role of the ‘capability’ of individual
> contributors, the collaborative, collegiate work environment
> and the ‘context’, a well funded organisation not dictating deadlines or
> product specifications for researchers.
>
> <snip>


I haven't heard of such a case study either. But you reminded me of an
analogy I once read. Please forgive me if my memory is incorrect or
incomplete.

I believe I read it in the book "The Supermen", and the idea might be
attributed to Seymour Cray. The basic idea was that any technical problem
can be solved with a shovel, where the sharpness of the blade represents
the astuteness of the people working on it, and the force applied to the
handle is how much money you throw at it. A bit simplistic, perhaps, but I
think there's also a lot of truth in it.

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Vincenzo Nicosia]

On Wed, Jul 03, 2024 at 02:51:01PM +1000, sjenkin@canb.auug.org.au wrote:
> I???ve never heard of a Computer Science or Software Engineering program
> that included a ???case study??? component, especially for Software Development & Projects.
> 
> MBA programs feature an emphasis on real-world ???case studies???, to learn from successes & failures,
> to give students the possibility of not falling into the same traps. 
> 
> Creating Unix V6, because it profoundly changed computing & development,
> would seem an obvious Case Study for many aspects of Software, Coding and Projects.
> 

I personally believe that the comparison of "mainstream" software
development principles and the birth and development of projects like
Unix, Linux, or any other major successful free software project is
fundamentally flawed. 

The programmers considered as "fungible workforce" by mainstream
software engineering and project management theories are *paid* to to
their programming job, and they mostly have to carry that job over
working on prescribed objectives and timelines which have been decided
by somebody else, managers who know nothing at all about software
development. Personal interest in the project, passion, motivation,
curiosity, creative power, sense of beauty, the joy of belonging to a
community of likeminded people, are never part of the equation, at any
point.

Remove one of those latter ingredients from Unix, Linux, or any other
major successful free/open source software project, and that project
would have not existed, at all. 

I think it would be terribly misleading to teach young CS students that
software projects should be managed "as Unix v6 came to life". They will
never, ever find anything even close to that environment in a
professional workplace. We should tell them that some of the most
beautiful software projects ever crafted by humans did not come out of
the "professionalism churches" that the overwhelming majority of
software companies are nowadays, based on  the blind application of
"mainstream" software development and project management principles,
according to which they (the CS majors) are just "as fungible and
replaceable as a chair, or a wallpaper". That would be only true and
fair to tell them. 

I don't know if that would be of any avail to them, but at least we do
not mislead them in thinking that their paid programming time will 
actually change the world in any meaningful way.....

My2cents

Enzo Nicosia

-- 

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Marc Donner]

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

There have been case study courses here and there over the years.  I would
argue that Lyons’s book of sources was the text for one.  An old crony, Ed
Smith, used to teach a comparative programming languages course back in the
day.  And I know someone at NYU taught a course where people studied the
source code of a variety of utilities.

=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>


On Wed, Jul 3, 2024 at 11:27 AM Vincenzo Nicosia <katolaz@freaknet.org>
wrote:

> On Wed, Jul 03, 2024 at 02:51:01PM +1000, sjenkin@canb.auug.org.au wrote:
> > I???ve never heard of a Computer Science or Software Engineering program
> > that included a ???case study??? component, especially for Software
> Development & Projects.
> >
> > MBA programs feature an emphasis on real-world ???case studies???, to
> learn from successes & failures,
> > to give students the possibility of not falling into the same traps.
> >
> > Creating Unix V6, because it profoundly changed computing & development,
> > would seem an obvious Case Study for many aspects of Software, Coding
> and Projects.
> >
>
> I personally believe that the comparison of "mainstream" software
> development principles and the birth and development of projects like
> Unix, Linux, or any other major successful free software project is
> fundamentally flawed.
>
> The programmers considered as "fungible workforce" by mainstream
> software engineering and project management theories are *paid* to to
> their programming job, and they mostly have to carry that job over
> working on prescribed objectives and timelines which have been decided
> by somebody else, managers who know nothing at all about software
> development. Personal interest in the project, passion, motivation,
> curiosity, creative power, sense of beauty, the joy of belonging to a
> community of likeminded people, are never part of the equation, at any
> point.
>
> Remove one of those latter ingredients from Unix, Linux, or any other
> major successful free/open source software project, and that project
> would have not existed, at all.
>
> I think it would be terribly misleading to teach young CS students that
> software projects should be managed "as Unix v6 came to life". They will
> never, ever find anything even close to that environment in a
> professional workplace. We should tell them that some of the most
> beautiful software projects ever crafted by humans did not come out of
> the "professionalism churches" that the overwhelming majority of
> software companies are nowadays, based on  the blind application of
> "mainstream" software development and project management principles,
> according to which they (the CS majors) are just "as fungible and
> replaceable as a chair, or a wallpaper". That would be only true and
> fair to tell them.
>
> I don't know if that would be of any avail to them, but at least we do
> not mislead them in thinking that their paid programming time will
> actually change the world in any meaningful way.....
>
> My2cents
>
> Enzo Nicosia
>
> --
>

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Jon Forrest]

On 7/3/24 8:35 AM, Marc Donner wrote:
> There have been case study courses here and there over the years.  I 
> would argue that Lyons’s book of sources was the text for one.  An old 
> crony, Ed Smith, used to teach a comparative programming languages 
> course back in the day.  And I know someone at NYU taught a course where 
> people studied the source code of a variety of utilities.

In the late 70s or early 80s there was an OS class at UC Santa Barbara
taught by John Bruno that used the Lions books of V6 Unix sources and
commentary. He had to go through some kind of special efforts to
get the books.

Jon

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[segaloco via TUHS]

On Wednesday, July 3rd, 2024 at 10:39 AM, Jon Forrest <nobozo@gmail.com> wrote:

> 
> On 7/3/24 8:35 AM, Marc Donner wrote:
> 
> > There have been case study courses here and there over the years. I
> > would argue that Lyons’s book of sources was the text for one. An old
> > crony, Ed Smith, used to teach a comparative programming languages
> > course back in the day. And I know someone at NYU taught a course where
> > people studied the source code of a variety of utilities.
> 
> 
> In the late 70s or early 80s there was an OS class at UC Santa Barbara
> taught by John Bruno that used the Lions books of V6 Unix sources and
> commentary. He had to go through some kind of special efforts to
> get the books.
> 
> Jon

I'm curious, if such a work was produced not from original specimens of the Bell Laboratories Sixth Edition source code, but rather someone sitting with a PDP-11 disassembler and meticulously stepping over the code, would publishing a work based on the latter analysis run afoul of the same legal circumstances as what John Lions published in the 70s?

I do have a pointed reason to ask: one of my long term goals is to write a case-study-type analysis of a Famicom/NES title, in other words, a John Lions-esque work based on one of my disassemblies of such a title.  The intention is to not only step through the (disassembled, not original) source code of a real world game and explain in detail precisely how it operates but also draw connections to other titles by the same development team and the historical conditions of the game's production.  I haven't seen such a work focused on a video game, and it's something I always wanted to sink my teeth into as a beginner, so my hope is I can use what I've learned over the years to provide for others what I once wanted in the past.

Something complicating the matter is console video games aren't licensed quite like operating systems or software utilities, it's typically an "All Rights Reserved" sort of situation rather than a lengthy license expounding on user rights, at least in my experience.  Anywho, curious what folks think, whether disassembly of a work a user does have license to (and of which the license makes no statement on reverse engineering/disassembly) can then be used by fair use or some other claim in an expository, non-commercial work.

- Matt G.

P.S. On the note of old UNIX reverse engineering ideas, is anyone aware of any early (early 80s and back) attempts to produce something akin to a C decompiler, something that could effectively analyze assembly produced by a C compiler and make a good guess as to what C made it up based on calling conventions, stack frames, known optimization techniques, etc?

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Erik E. Fair]

>Date: Wed, 03 Jul 2024 17:49:29 +0000
>From: segaloco via TUHS <tuhs@tuhs.org>
>
>P.S. On the note of old UNIX reverse engineering ideas, is anyone aware of any early (early 80s and back) attempts to produce something akin to a C decompiler, something that could effectively analyze assembly produced by a C compiler and make a good guess as to what C made it up based on calling conventions, stack frames, known optimization techniques, etc?


Yes: Dave Pare produced a C decompiler to analyze and fix bugs in PSL's (binary distribution only) "Empire" game, and that set of tools was subsequently used to analyze the Morris Worm in 1988.

https://www.empire.cx/newssept1694.html#interview

https://www.quora.com/What-was-it-like-to-experience-the-Morris-Worm/answer/Erik-Fair

	Erik Fair

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Rich Salz]

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

I would be careful of disassembly in the United States. There are laws
about that; the Digital Millennium Copyright Act, probably others.

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Dave Horsfall]

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

> I would argue that Lyons’s book of sources was the text for one.

Sigh...  Can people please spell his name correctly?  It's Lions, not 
Lyons (he was one of my lecturers, OK?).

-- Dave

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Marc Donner]

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

Apologies … I was shooting from memory … my copy is not where I am.

=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>


On Wed, Jul 3, 2024 at 7:15 PM Dave Horsfall <dave@horsfall.org> wrote:

> > I would argue that Lyons’s book of sources was the text for one.
>
> Sigh...  Can people please spell his name correctly?  It's Lions, not
> Lyons (he was one of my lecturers, OK?).
>
> -- Dave

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Rik Farrow]

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

Although off-topic, except by including Lions: twice in the early 80s, a
programmer handed me a binder with the Lions book as a several generations
old xerox copy. It was always in the programmer/engineer part of a
warehouse (like Morrow), and it was handed to me as if it were something
illegal.

I guess it was.

Rik


On Wed, Jul 3, 2024 at 4:15 PM Dave Horsfall <dave@horsfall.org> wrote:

> > I would argue that Lyons’s book of sources was the text for one.
>
> Sigh...  Can people please spell his name correctly?  It's Lions, not
> Lyons (he was one of my lecturers, OK?).
>
> -- Dave

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Dave Horsfall]

On Wed, 3 Jul 2024, Rik Farrow wrote:

> Although off-topic, except by including Lions: twice in the early 80s, a 
> programmer handed me a binder with the Lions book as a several 
> generations old xerox copy. It was always in the programmer/engineer 
> part of a warehouse (like Morrow), and it was handed to me as if it were 
> something illegal. I guess it was.

The most photocopied book in the world, I lost my originals during a house 
move :-(

Almost certainly illegal, but somehow I think that Dr. Lions would have
approved...

-- Dave

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Al Kossow]

On 7/3/24 8:17 AM, Vincenzo Nicosia wrote:

> I think it would be terribly misleading to teach young CS students that
> software projects should be managed "as Unix v6 came to life". They will
> never, ever find anything even close to that environment in a
> professional workplace. We should tell them that some of the most
> beautiful software projects ever crafted by humans did not come out of
> the "professionalism churches" that the overwhelming majority of
> software companies are nowadays, based on  the blind application of
> "mainstream" software development and project management principles,
> according to which they (the CS majors) are just "as fungible and
> replaceable as a chair, or a wallpaper". That would be only true and
> fair to tell them.
> 

I was inside Apple for a LONG time, and if you were going to write a
horror story case history, the Mac OS would be it, right through the
death march that occurred during the OS X transition (bringing this
around to Unix history). You don't hear anything about the people
past the "Magnificent Seven" of the original Mac team. There were
many and many people were burned out in the process, including almost
all of the original team one way or another.

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Al Kossow]

> On 7/3/24 8:17 AM, Vincenzo Nicosia wrote:
> 
>> I think it would be terribly misleading to teach young CS students that
>> software projects should be managed "as Unix v6 came to life". They will
>> never, ever find anything even close to that environment in a
>> professional workplace.
Also, it is unlikely they will ever bootstrap an operating system from scratch.
No company would invest its resources doing so when they can find something
for free that will be "good enough".
It isn't even likely they will implement any major new libraries or compilers
and will just use what is out there already. Again, a project "make vs buy"
even if the "buy" is free as in beer.

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Warner Losh]

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

On Wed, Jul 3, 2024 at 10:01 AM Al Kossow <aek@bitsavers.org> wrote:

> > On 7/3/24 8:17 AM, Vincenzo Nicosia wrote:
> >
> >> I think it would be terribly misleading to teach young CS students that
> >> software projects should be managed "as Unix v6 came to life". They will
> >> never, ever find anything even close to that environment in a
> >> professional workplace.
> Also, it is unlikely they will ever bootstrap an operating system from
> scratch.
> No company would invest its resources doing so when they can find something
> for free that will be "good enough".
> It isn't even likely they will implement any major new libraries or
> compilers
> and will just use what is out there already. Again, a project "make vs buy"
> even if the "buy" is free as in beer.
>

Yea, even in the 80s when I was in school, the CS department switched from
running the HW simulator on the HW in question, and we had to write
everything
to bring up the HW on the DEC-20 (well, simplified DEC-20) to linking in
your code
to the SunOS kernel on the 68k Sun3 machines that were plentiful and doing
the
debugging on real hardware. I'm not sure there's a lot of students that
have done
a full, from scratch, bootstrap of a real OS (or even a Toy one) these
days...  Though
a lot of activity there has shifted to the cheap embedded world where it's
easy to
write a bare-metal app that has many of the features of an OS, but in some
weird,
specialized way.

Warner

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Marc Rochkind]

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

On Wed, Jul 3, 2024 at 9:27 AM Vincenzo Nicosia <katolaz@freaknet.org>
wrote:

> ...
>
> The programmers considered as "fungible workforce" by mainstream
> software engineering and project management theories are *paid* to to
> their programming job, and they mostly have to carry that job over
> working on prescribed objectives and timelines which have been decided
> by somebody else, managers who know nothing at all about software
> development. Personal interest in the project, passion, motivation,
> curiosity, creative power, sense of beauty, the joy of belonging to a
> community of likeminded people, are never part of the equation, at any
> point.
>
>
What a cynical take on software development! The logical error is to assume
that if something is sometimes true (e.g., " managers who know nothing at
all about software development") then it is always true.

My experience over many decades is quite different. Most often, managers
know software quite well. Where they fail is in their very poor
understanding of how to manage people.

The bias that operates in software development, and perhaps all
organizations, is that when there is a disagreement between management and
non-management (e.g., programmers), the non-managers usually assume that
they are always right and the managers are wrong.

I have never met a programmer or group of programmers who were always
right. Most often, they are ignorant of financing, regulatory constraints,
product schedules, commitments, staffing issues, and everything else that
isn't coding. (There are exceptions, but they are uncommon.) Management, by
definition, is the art and science of using resources to reach an
objective. Programmers generally are concerned only with themselves as a
resource and with their own personal programming objective. It is unusual
to find a programmer who understands management.

Marc

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[G. Branden Robinson]

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

Getting in before the COFF boom lowers...  :-O

At 2024-07-03T17:29:26-0600, Marc Rochkind wrote:
> > The programmers considered as "fungible workforce" by mainstream
> > software engineering and project management theories are *paid* to
> > to their programming job, and they mostly have to carry that job
> > over working on prescribed objectives and timelines which have been
> > decided by somebody else, managers who know nothing at all about
> > software development. Personal interest in the project, passion,
> > motivation, curiosity, creative power, sense of beauty, the joy of
> > belonging to a community of likeminded people, are never part of the
> > equation, at any point.
>
> What a cynical take on software development!

There's some truth to it.  But I'd agree that it is not the whole story.

> The logical error is to assume that if something is sometimes true
> (e.g., "managers who know nothing at all about software development")
> then it is always true.

Yes, and this fallacy is a popular one among almost any sample of humans
one takes.

> My experience over many decades is quite different. Most often,
> managers know software quite well. Where they fail is in their very
> poor understanding of how to manage people.

This aligns closely with my experience.  Often the worst managers I've
had were those who had the best programming "chops".

> The bias that operates in software development, and perhaps all
> organizations, is that when there is a disagreement between management
> and non-management (e.g., programmers), the non-managers usually
> assume that they are always right and the managers are wrong.

An obvious solution to this sort of problem, long held to be inherently
horrific, is to cultivate a more mature perspective on management, and
skill at performing it, by having workers manage themselves.  One often
finds this insight at or near the heart of "revolutionary" approaches to
software development like Agile or Lean, sometimes under many layers of
obfuscation to avoid alarming MBAs and others whose career plans from
adolescence involved going directly into professional management from
university.

That solution is, of course, worker self-management.

> I have never met a programmer or group of programmers who were always
> right. Most often, they are ignorant of financing, regulatory
> constraints, product schedules, commitments, staffing issues, and
> everything else that isn't coding.  (There are exceptions, but they
> are uncommon.)

Indeed.  One way to overcome this ignorance and produce more exceptions
is to educate one's staff in these very phenomena.  I won't digress on
why this doesn't often happen in practice.  It doesn't take much
imagination, or professional experience, to reason it out.

> Management, by definition, is the art and science of using resources
> to reach an objective.

Stated this broadly, programmers solve management problems all the time.
Mightn't their skills "port"?

> Programmers generally are concerned only with themselves as a
> resource and with their own personal programming objective.

If I s/Programmers/People/;s/progamming//, then I find this statement
no less true.  Cooperators and defectors appear in every aspect of life.

> It is unusual to find a programmer who understands management.

As noted, a solution exists.  But it is an unpalatable one to those
touted, by themselves or others, as "thought leaders".

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Vincenzo Nicosia]

On Wed, Jul 03, 2024 at 05:29:26PM -0600, Marc Rochkind wrote:
> On Wed, Jul 3, 2024 at 9:27???AM Vincenzo Nicosia <katolaz@freaknet.org>
> wrote:
> 
> > ...
> >
> > The programmers considered as "fungible workforce" by mainstream
> > software engineering and project management theories are *paid* to to
> > their programming job, and they mostly have to carry that job over
> > working on prescribed objectives and timelines which have been decided
> > by somebody else, managers who know nothing at all about software
> > development. Personal interest in the project, passion, motivation,
> > curiosity, creative power, sense of beauty, the joy of belonging to a
> > community of likeminded people, are never part of the equation, at any
> > point.
> >
> >

[cut]

> 
> I have never met a programmer or group of programmers who were always
> right. Most often, they are ignorant of financing, regulatory constraints,
> product schedules, commitments, staffing issues, and everything else that
> isn't coding. (There are exceptions, but they are uncommon.) Management, by
> definition, is the art and science of using resources to reach an
> objective. Programmers generally are concerned only with themselves as a
> resource and with their own personal programming objective. It is unusual
> to find a programmer who understands management.
> 


I agree my view is cynical. Maybe that's because I cannot find anything
romantic or poetic in "financing, regulatory constraints, product
schedules, commitments, staffing issues, and everything else that isn't
coding". Maybe because I have learned on experience that those things
are just there to ensure that the clients pay their invoices, while they
rarely contribute to anything durable, well-engineered, great, or
beautiful. Anything that can be considered a truly good case study of
software development. But I am sure I am just too cynical here :)

HND

Enzo

-- 

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Nevin Liber]

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

On Thu, Jul 4, 2024 at 3:24 AM Vincenzo Nicosia <katolaz@freaknet.org>
wrote:

> I agree my view is cynical. Maybe that's because I cannot find anything
> romantic or poetic in "financing, regulatory constraints, product
> schedules, commitments, staffing issues, and everything else that isn't
> coding".


Real Artists Ship:  https://folklore.org/Real_Artists_Ship.html

How would you have ever seen Unix had it not been for financing (engineers,
even passionate ones, kind of like to eat and have a roof over their
heads)?  Without regulatory constraints (while not perfect), applying Unix
to anything that is safety critical (lives directly on the line) would be a
disaster.  I can make a similar statement for every single thing in that
list which isn't coding.

There are something like 28 million public repositories on Github.  How
many of them are abandoned (no commitment)?  How many of them are
"beautiful" (for any reasonable definition of "beautiful" you can come up
with)?  Even 1%?  Of those, how many of them have corporate backing (money,
financing, staffing, etc.)?

It's fine to romanticize passion.  But it is also fiction.
-- 
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[segaloco via TUHS]

On Thursday, July 4th, 2024 at 1:34 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> 
> There are something like 28 million public repositories on Github. How many of them are abandoned (no commitment)? 
> ...
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404

I do appreciate that, while yes there are a lot of abandoned threads on various public source control providers, that those threads are indeed public and could be picked back up by the right person in certain circumstances.  I've benefitted more than once from someone leaving something up, even if I had to pay a bit of technical debt myself to get use out of it.  While entropy levies its tax over time, it's better than things disappearing into some black hole, never to be seen again.

As much as I don't like the LLM trend, one application of the modern trend of generative LLMs could be plundering the depths of all of this code (respective of licensing of course) to dredge up hidden nuggets just waiting to be discovered.  Everything useful gets invented at some point, I have to wonder what's sitting in some abandoned repo somewhere just waiting to fit someone's use-case like hand in glove.  After all, isn't that one of the many reasons we go digging around in decades-old UNIX code still :)

- Matt G.

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[sjenkin]

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

Thanks to everyone who’s contributed to this thread.
Lots of good insight and views.

I should’ve said “case studies in software development”.

Summary:
	Nobody on list has heard of such case studies.

I took the Lions class, it was not about development, taught us Operating Systems.

John had a pedagogical principle - people learn programming by reading good code.

> On 5 Jul 2024, at 06:44, segaloco via TUHS <tuhs@tuhs.org> wrote:
> 
> On Thursday, July 4th, 2024 at 1:34 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> 
>> 
>> There are something like 28 million public repositories on Github. How many of them are abandoned (no commitment)? 
>> ...
>> --
>> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
> 
> I do appreciate that, while yes there are a lot of abandoned threads on various public source control providers, that those threads are indeed public and could be picked back up by the right person in certain circumstances.  I've benefitted more than once from someone leaving something up, even if I had to pay a bit of technical debt myself to get use out of it.  While entropy levies its tax over time, it's better than things disappearing into some black hole, never to be seen again.
> 
> As much as I don't like the LLM trend, one application of the modern trend of generative LLMs could be plundering the depths of all of this code (respective of licensing of course) to dredge up hidden nuggets just waiting to be discovered.  Everything useful gets invented at some point, I have to wonder what's sitting in some abandoned repo somewhere just waiting to fit someone's use-case like hand in glove.  After all, isn't that one of the many reasons we go digging around in decades-old UNIX code still :)
> 
> - Matt G.


--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin


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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Steve Jenkin]

Links for those who’ve not read these articles. Open access, downloadable PDF’s.

================

Peter J Denning in 2008 wrote about reforming CACM in 1982/83. [ extract at end ]
	<https://cacm.acm.org/opinion/dja-vu-all-over-again/>

The space shuttle primary computer system
	Sept 1984
	<https://dl.acm.org/doi/10.1145/358234.358246>

The TWA reservation system
	July 1984
	<https://dl.acm.org/doi/abs/10.1145/358105.358192>

================

After Editor in Chief of the ACM, in 1993 Denning established "The Center for the New Engineer" (CNE)
	<http://www.denninginstitute.com/cne/cne-aug93.pdf>

Great Principles of Computing, paper
	<https://denninginstitute.com/pjd/PUBS/ENC/gp08.pdf>

Website
	<https://denninginstitute.com/pjd/GP/GP-site/welcome.html>

================
Denning, 2008

Another major success was the case studies conducted by Alfred Spector and David Gifford of MIT, 
who visited project managers and engineers at major companies and interviewed them about their projects, 
producing no-holds-barred pieces. 

This section was wildly popular among the readers. 
Unfortunately, the labor-intensive demands of the post got the best of them after three years, and we were not able to replace them. 

Also by that time, companies were getting more circumspect about discussing failures and lessons learned in public forums.

================

> On 5 Jul 2024, at 09:31, Lawrence Stewart <stewart@serissa.com> wrote:
> 
> Alright, apologies for being late.
> 
> Back in 1984, David Gifford and Al Spector started a series of case studies for CACM.
> I think only two were published, on the TWA reservation system and on the Space Shuttle primary computer.


--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Steve Jenkin]

Found these two.
Anyone seen others?

I bought this book soon after it was published.
It’s a detailed study of some major IT projects, doesn’t draw “lessons” & rules like I’d expect of an MBA Case Study.

	Why information systems fail: a case study approach
	February 1993
	<https://dl.acm.org/doi/book/10.5555/174553> 

> On 5 Jul 2024, at 09:31, Lawrence Stewart <stewart@serissa.com> wrote:
> 
> A quick search also shows a number of software engineering case study books.

================

Case Study Research in Software Engineering: Guidelines and Examples
	April 2012
	<https://dl.acm.org/doi/book/10.5555/2361717>

	Based on their own experiences of in-depth case studies of software projects in international corporations,
	in this bookthe authors present detailed practical guidelines on 
		the preparation, conduct, design and reporting of case studies of software engineering. 

	This is the first software engineering specific book on thecase study research method.

================

Case studies for software engineers
	May 2006
	<https://dl.acm.org/doi/10.1145/1134285.1134497>

	The topic of this full-day tutorial was the correct use and interpretation of case studies as an empirical research method. 
	Using an equal blend of lecture and discussion, it gave attendees 
		a foundation for conducting, reviewing, and reading case studies. 

	There were lessons for software engineers as researchers who 
		conduct and report case studies, reviewers who evaluate papers, 
		and practitioners who are attempting to apply results from papers. 

	The main resource for the course was the book 
		Case Study Research: Design and Methods by Robert K. Yin. 

	This text was supplemented with positive and negative examples from the literature.

================

--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Stuff Received]

On 2024-07-04 16:34, Nevin Liber wrote (in part):
> On Thu, Jul 4, 2024 at 3:24 AM Vincenzo Nicosia <katolaz@freaknet.org 
> <mailto:katolaz@freaknet.org>> wrote:
> 
>     I agree my view is cynical. Maybe that's because I cannot find anything
>     romantic or poetic in "financing, regulatory constraints, product
>     schedules, commitments, staffing issues, and everything else that isn't
>     coding". 
> 
> 
> Real Artists Ship: https://folklore.org/Real_Artists_Ship.html 
> <https://folklore.org/Real_Artists_Ship.html>
> 
> How would you have ever seen Unix had it not been for financing 
> (engineers, even passionate ones, kind of like to eat and have a roof 
> over their heads)?  Without regulatory constraints (while not perfect), 
> applying Unix to anything that is safety critical (lives directly on the 
> line) would be a disaster.  I can make a similar statement for every 
> single thing in that list which isn't coding.

In full agreement.  Having worked at startups, engineers often do all of 
these other tasks and know their importance.

Though not full case studies, chapter 5 of "Evidence based software 
engineering" by Derek Jones has interesting project cases.

S.

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Larry McVoy]

On Thu, Jul 04, 2024 at 08:03:10PM -0400, Stuff Received wrote:
> On 2024-07-04 16:34, Nevin Liber wrote (in part):
> >On Thu, Jul 4, 2024 at 3:24???AM Vincenzo Nicosia <katolaz@freaknet.org
> ><mailto:katolaz@freaknet.org>> wrote:
> >
> >    I agree my view is cynical. Maybe that's because I cannot find anything
> >    romantic or poetic in "financing, regulatory constraints, product
> >    schedules, commitments, staffing issues, and everything else that isn't
> >    coding".
> >
> >
> >Real Artists Ship: https://folklore.org/Real_Artists_Ship.html
> ><https://folklore.org/Real_Artists_Ship.html>
> >
> >How would you have ever seen Unix had it not been for financing
> >(engineers, even passionate??ones, kind of like to eat and have a roof
> >over their heads)??? Without regulatory??constraints (while not perfect),
> >applying Unix to anything that is safety critical (lives directly on the
> >line) would be a disaster.?? I can make a similar statement for every
> >single thing in that list which isn't coding.
> 
> In full agreement.  Having worked at startups, engineers often do all of
> these other tasks and know their importance.

I'm friends with one of the ZFS guys (and I hired the other guy at Sun)
and one Bill's interview questions for a startup candidate is "If we 
need you to, will you sweep the floors".  Bill likes people who can 
do whatever is needed.

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Adam Thornton]

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

Two replies to things Larry said:

ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular)
would be a perfectly reasonable architecture to learn these days.  After
the PDP-11 but before ARM I'd'a suggested 68000.  Definitely NOT x86 and
its betentacled descendants.  Even so, you'd still want to treat it (if
you're learning "how do computers work?") as if it were not superscalar,
even though it obviously is.  Which I guess is pushing me into "please let
me just pretend it's a PDP-11 and keep all the scary pipelining and
speculative execution and all the things that are hard to reason about
below the layer where I need to care" territory.

And yeah, if you need me to sweep the floors, I'll sweep the floors, but if
I'm needed to sweep the floors often, there's a management problem here, in
that you can hire people who are much better at sweeping floors than I am
for much less money than you hired me to do software engineering for.

Adam

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Bakul Shah via TUHS]

A better analogy might be to compare early employees (especially engineers) to stem cells. They are the type of people that can (& are willing to) do pretty much anything but over time end up specializing in a few things. I have done things like look at office spaces, set up furniture, order machines & office supplies, select ISP, wired up the place, and many sysadmin things, dealt with janitorial services, selecting insurance, payroll services, debugged issues not related to engineering, many interviews (tech and otherwise), dealt with vendors & headhunters, set up guidelines, software systems, documentation, etc. etc. As times goes on you let go and get out of people's way and focus on where you're most effective (or where there is temporarily no one else).

> On Jul 4, 2024, at 7:24 PM, Adam Thornton <athornton@gmail.com> wrote:
> 
> Two replies to things Larry said:
> 
> ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) would be a perfectly reasonable architecture to learn these days.  After the PDP-11 but before ARM I'd'a suggested 68000.  Definitely NOT x86 and its betentacled descendants.  Even so, you'd still want to treat it (if you're learning "how do computers work?") as if it were not superscalar, even though it obviously is.  Which I guess is pushing me into "please let me just pretend it's a PDP-11 and keep all the scary pipelining and speculative execution and all the things that are hard to reason about below the layer where I need to care" territory.
> 
> And yeah, if you need me to sweep the floors, I'll sweep the floors, but if I'm needed to sweep the floors often, there's a management problem here, in that you can hire people who are much better at sweeping floors than I am for much less money than you hired me to do software engineering for.
> 
> Adam

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[arnold]

The flip side is when you're asked to do something you're not competent
at. At Intel, I was once tasked in reviewing the license for something
we wanted to use. I Am Not A Lawyer, nor do I play one on TV. I did my
best, but got fussed at by a higher-up for it not being good enough.

I'm sorry, but that bullsh*t --- Intel has lawyers out the wazoo, and
that's who should have been involved in reviewing that license.

Would you take your car to TV repair shop to get fixed? Same thing.

Arnold

Bakul Shah via TUHS <tuhs@tuhs.org> wrote:

> A better analogy might be to compare early employees (especially
> engineers) to stem cells. They are the type of people that can (& are
> willing to) do pretty much anything but over time end up specializing
> in a few things. I have done things like look at office spaces, set up
> furniture, order machines & office supplies, select ISP, wired up the
> place, and many sysadmin things, dealt with janitorial services, selecting
> insurance, payroll services, debugged issues not related to engineering,
> many interviews (tech and otherwise), dealt with vendors & headhunters,
> set up guidelines, software systems, documentation, etc. etc. As times
> goes on you let go and get out of people's way and focus on where you're
> most effective (or where there is temporarily no one else).
>
> > On Jul 4, 2024, at 7:24 PM, Adam Thornton <athornton@gmail.com> wrote:
> > 
> > Two replies to things Larry said:
> > 
> > ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) would be a perfectly reasonable architecture to learn these days.  After the PDP-11 but before ARM I'd'a suggested 68000.  Definitely NOT x86 and its betentacled descendants.  Even so, you'd still want to treat it (if you're learning "how do computers work?") as if it were not superscalar, even though it obviously is.  Which I guess is pushing me into "please let me just pretend it's a PDP-11 and keep all the scary pipelining and speculative execution and all the things that are hard to reason about below the layer where I need to care" territory.
> > 
> > And yeah, if you need me to sweep the floors, I'll sweep the floors, but if I'm needed to sweep the floors often, there's a management problem here, in that you can hire people who are much better at sweeping floors than I am for much less money than you hired me to do software engineering for.
> > 
> > Adam
>

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Bakul Shah via TUHS]

I was talking about startups, while in a bootstrapping mode. Intel stopped being that a looong time ago! But yes, I wouldn't want to play a lawyer!

In a startup there are lots of other things that need done and you of course try to hire/contract the right people but it isn't always easy or quick.

> On Jul 5, 2024, at 12:13 AM, arnold@skeeve.com wrote:
> 
> The flip side is when you're asked to do something you're not competent
> at. At Intel, I was once tasked in reviewing the license for something
> we wanted to use. I Am Not A Lawyer, nor do I play one on TV. I did my
> best, but got fussed at by a higher-up for it not being good enough.
> 
> I'm sorry, but that bullsh*t --- Intel has lawyers out the wazoo, and
> that's who should have been involved in reviewing that license.
> 
> Would you take your car to TV repair shop to get fixed? Same thing.
> 
> Arnold
> 
> Bakul Shah via TUHS <tuhs@tuhs.org> wrote:
> 
>> A better analogy might be to compare early employees (especially
>> engineers) to stem cells. They are the type of people that can (& are
>> willing to) do pretty much anything but over time end up specializing
>> in a few things. I have done things like look at office spaces, set up
>> furniture, order machines & office supplies, select ISP, wired up the
>> place, and many sysadmin things, dealt with janitorial services, selecting
>> insurance, payroll services, debugged issues not related to engineering,
>> many interviews (tech and otherwise), dealt with vendors & headhunters,
>> set up guidelines, software systems, documentation, etc. etc. As times
>> goes on you let go and get out of people's way and focus on where you're
>> most effective (or where there is temporarily no one else).
>> 
>>> On Jul 4, 2024, at 7:24 PM, Adam Thornton <athornton@gmail.com> wrote:
>>> 
>>> Two replies to things Larry said:
>>> 
>>> ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) would be a perfectly reasonable architecture to learn these days.  After the PDP-11 but before ARM I'd'a suggested 68000.  Definitely NOT x86 and its betentacled descendants.  Even so, you'd still want to treat it (if you're learning "how do computers work?") as if it were not superscalar, even though it obviously is.  Which I guess is pushing me into "please let me just pretend it's a PDP-11 and keep all the scary pipelining and speculative execution and all the things that are hard to reason about below the layer where I need to care" territory.
>>> 
>>> And yeah, if you need me to sweep the floors, I'll sweep the floors, but if I'm needed to sweep the floors often, there's a management problem here, in that you can hire people who are much better at sweeping floors than I am for much less money than you hired me to do software engineering for.
>>> 
>>> Adam
>> 

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[arnold]

To a large extent it still applies in startups. If a software person
doesn't know the first thing about wiring a building for Ethernet,
do you really want him/her to do that for you?  In situations like
these, you get what you pay for, and it's better to bring in someone
who knows what they're doing in order to get it done right. (Yes, I
had that experience too.)

I do understand your point, in startups people have to be flexible
and do many things, but it still should require some consideration
for the longer term.

Bakul Shah <bakul@iitbombay.org> wrote:

> I was talking about startups, while in a bootstrapping mode. Intel stopped
> being that a looong time ago! But yes, I wouldn't want to play a lawyer!
> 
> In a startup there are lots of other things that need done and you of
> course try to hire/contract the right people but it isn't always easy
> or quick.
>
> > On Jul 5, 2024, at 12:13 AM, arnold@skeeve.com wrote:
> > 
> > The flip side is when you're asked to do something you're not competent
> > at. At Intel, I was once tasked in reviewing the license for something
> > we wanted to use. I Am Not A Lawyer, nor do I play one on TV. I did my
> > best, but got fussed at by a higher-up for it not being good enough.
> > 
> > I'm sorry, but that bullsh*t --- Intel has lawyers out the wazoo, and
> > that's who should have been involved in reviewing that license.
> > 
> > Would you take your car to TV repair shop to get fixed? Same thing.
> > 
> > Arnold
> > 
> > Bakul Shah via TUHS <tuhs@tuhs.org> wrote:
> > 
> >> A better analogy might be to compare early employees (especially
> >> engineers) to stem cells. They are the type of people that can (& are
> >> willing to) do pretty much anything but over time end up specializing
> >> in a few things. I have done things like look at office spaces, set up
> >> furniture, order machines & office supplies, select ISP, wired up the
> >> place, and many sysadmin things, dealt with janitorial services, selecting
> >> insurance, payroll services, debugged issues not related to engineering,
> >> many interviews (tech and otherwise), dealt with vendors & headhunters,
> >> set up guidelines, software systems, documentation, etc. etc. As times
> >> goes on you let go and get out of people's way and focus on where you're
> >> most effective (or where there is temporarily no one else).
> >> 
> >>> On Jul 4, 2024, at 7:24 PM, Adam Thornton <athornton@gmail.com> wrote:
> >>> 
> >>> Two replies to things Larry said:
> >>> 
> >>> ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) would be a perfectly reasonable architecture to learn these days.  After the PDP-11 but before ARM I'd'a suggested 68000.  Definitely NOT x86 and its betentacled descendants.  Even so, you'd still want to treat it (if you're learning "how do computers work?") as if it were not superscalar, even though it obviously is.  Which I guess is pushing me into "please let me just pretend it's a PDP-11 and keep all the scary pipelining and speculative execution and all the things that are hard to reason about below the layer where I need to care" territory.
> >>> 
> >>> And yeah, if you need me to sweep the floors, I'll sweep the floors, but if I'm needed to sweep the floors often, there's a management problem here, in that you can hire people who are much better at sweeping floors than I am for much less money than you hired me to do software engineering for.
> >>> 
> >>> Adam
> >> 
>

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[G. Branden Robinson]

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

At 2024-07-05T02:20:31-0600, arnold@skeeve.com wrote:
> To a large extent it still applies in startups.
[...]
> I do understand your point, in startups people have to be flexible
> and do many things, but it still should require some consideration
> for the longer term.

Consideration for the longer term is completely _not_ the point of a
speculatively financed startup.

The idea is to convince enough Series B investors, or an underwriting
bank that will float your IPO, that you have a sure thing in hand, that
you've identified a choke point in the market, and your firm will be
able to extract gigantic rents for an extended period by squeezing that
choke point.

The long term is often not long.  But if you, with founder's stock, can
get out clean before your brilliant strategy is revealed as a moronic
façade, you've met your victory condition.

And if you don't?  Practice blaming other people for your failure and
try, try again.  Steve Jobs wasn't built in a day.

https://ca.finance.yahoo.com/news/27-billion-smoke-ndash-thats-125443313.html

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Dave Horsfall]

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

On Thu, 4 Jul 2024, Adam Thornton wrote:

> ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) 
> would be a perfectly reasonable architecture to learn these days.  After 
> the PDP-11 but before ARM I'd'a suggested 68000.  Definitely NOT x86 and 
> its betentacled descendants.  Even so, you'd still want to treat it (if 
> you're learning "how do computers work?") as if it were not superscalar, 
> even though it obviously is.  Which I guess is pushing me into "please 
> let me just pretend it's a PDP-11 and keep all the scary pipelining and 
> speculative execution and all the things that are hard to reason about 
> below the layer where I need to care" territory.

Pretty much anything with a linear address space, an orthogonal 
instruction set, and a stack will do, I think.

Was it John Gilmore who said "Segment registers are for worms"?

I dips me lid to those souls who implemented ALGOLW on the 360...

> And yeah, if you need me to sweep the floors, I'll sweep the floors, but 
> if I'm needed to sweep the floors often, there's a management problem 
> here, in that you can hire people who are much better at sweeping floors 
> than I am for much less money than you hired me to do software 
> engineering for.

I've worked in places where I've swept the floor (and also did the dishes 
etc); I'll still need to be paid the same salary, though :-)

-- Dave

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Peter Yardley]

The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, program counter, status register. No stack register tho. There was a micro processor version by Fairchild. 

Sent from my iPhone

> On 5 Jul 2024, at 5:36 pm, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Thu, 4 Jul 2024, Adam Thornton wrote:
> 
>> ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) 
>> would be a perfectly reasonable architecture to learn these days.  After 
>> the PDP-11 but before ARM I'd'a suggested 68000.  Definitely NOT x86 and 
>> its betentacled descendants.  Even so, you'd still want to treat it (if 
>> you're learning "how do computers work?") as if it were not superscalar,
>> even though it obviously is.  Which I guess is pushing me into "please 
>> let me just pretend it's a PDP-11 and keep all the scary pipelining and 
>> speculative execution and all the things that are hard to reason about 
>> below the layer where I need to care" territory.
> 
> Pretty much anything with a linear address space, an orthogonal 
> instruction set, and a stack will do, I think.
> 
> Was it John Gilmore who said "Segment registers are for worms"?
> 
> I dips me lid to those souls who implemented ALGOLW on the 360...
> 
>> And yeah, if you need me to sweep the floors, I'll sweep the floors, but 
>> if I'm needed to sweep the floors often, there's a management problem 
>> here, in that you can hire people who are much better at sweeping floors 
>> than I am for much less money than you hired me to do software 
>> engineering for.
> 
> I've worked in places where I've swept the floor (and also did the dishes 
> etc); I'll still need to be paid the same salary, though :-)
> 
> -- Dave

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[John Levine]

It appears that Peter Yardley <peter.martin.yardley@gmail.com> said:
>The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, program counter, status register. No stack register tho. There was a micro processor version by Fairchild. 

It did, but it was word addressed which makes it an historical
curiosity like its spiritual predecessors PDP-4/5/7/8/9.

I also have a mental model of a PDP-11 but these days it's more a simplified 386
leaving out the dumb or useless stuff.  I ignore the segments which are useless
other than for 286 emulation, and some of the strange instructions like decimal
adjust and the warty 8 and 16 bit registers.

What's important is the memory model which on a 386 the way it was
invariably set up was a flat 32 bit consistent little-endian byte
addressed memory with a stack and reasonable addressing modes, and 4K
pages for virtual memory.

ARM should be OK too but I have to ask which ARM? There have been so
many generations often not backward compatible.

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[Larry McVoy]

On Fri, Jul 05, 2024 at 05:38:03PM -0400, John Levine wrote:
> It appears that Peter Yardley <peter.martin.yardley@gmail.com> said:
> >The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, program counter, status register. No stack register tho. There was a micro processor version by Fairchild. 
> 
> It did, but it was word addressed which makes it an historical
> curiosity like its spiritual predecessors PDP-4/5/7/8/9.
> 
> I also have a mental model of a PDP-11 but these days it's more a simplified 386
> leaving out the dumb or useless stuff.  

I took a look at x86 in 386/486 days and found it to be enough of a mess that
I stopped looking.  In no way did it compare the simplicity and elegance 
of the PDP-11.  I had a TA, Ken Witte, who could read octal dumps of PDP-11
assembly like it was C.  I'm pretty sure the way the instructions were
encoded was a big part of what made that possible.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[Charles H Sauer (he/him)]

On 7/5/2024 4:49 PM, Larry McVoy wrote:
> On Fri, Jul 05, 2024 at 05:38:03PM -0400, John Levine wrote:
>> It appears that Peter Yardley <peter.martin.yardley@gmail.com> said:
>>> The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, program counter, status register. No stack register tho. There was a micro processor version by Fairchild.
>>
>> It did, but it was word addressed which makes it an historical
>> curiosity like its spiritual predecessors PDP-4/5/7/8/9.
>>
>> I also have a mental model of a PDP-11 but these days it's more a simplified 386
>> leaving out the dumb or useless stuff.
> 
> I took a look at x86 in 386/486 days and found it to be enough of a mess that
> I stopped looking.  In no way did it compare the simplicity and elegance
> of the PDP-11.  I had a TA, Ken Witte, who could read octal dumps of PDP-11
> assembly like it was C.  I'm pretty sure the way the instructions were
> encoded was a big part of what made that possible.

Assuming you mean the same Kendall Witte that spearheaded Dell SVR4 
(https://notes.technologists.com/notes/2008/01/10/a-brief-history-of-dell-unix/), 
he is quite fluent in X86 as well. After Dell SVR4 he became prominent 
in Dell firmware work. I saw him just over a year ago at a gathering of 
Dell "old timers".

-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/LinkedIn/Twitter: CharlesHSauer

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[Larry McVoy]

On Fri, Jul 05, 2024 at 05:08:01PM -0500, Charles H Sauer (he/him) wrote:
> Assuming you mean the same Kendall Witte that spearheaded Dell SVR4 (https://notes.technologists.com/notes/2008/01/10/a-brief-history-of-dell-unix/),
> he is quite fluent in X86 as well. After Dell SVR4 he became prominent in
> Dell firmware work. I saw him just over a year ago at a gathering of Dell
> "old timers".

Yep, that's him.  I have fond memories of bring a six pack and an octal
dump to his place and him swigging a beer and reading it with ease.
Great guy.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[John Levine]

According to Larry McVoy <lm@mcvoy.com>:
>> It did, but it was word addressed which makes it an historical
>> curiosity like its spiritual predecessors PDP-4/5/7/8/9.
>> 
>> I also have a mental model of a PDP-11 but these days it's more a simplified 386
>> leaving out the dumb or useless stuff.  
>
>I took a look at x86 in 386/486 days and found it to be enough of a mess that
>I stopped looking.  In no way did it compare the simplicity and elegance 
>of the PDP-11. 

If you're looking for simplicity and elegance, I can still remember most
of the PDP-8's instruction codes so I could disassemble at sight.  But
it's not a very good model for a modern computer.

I realized a while ago that the only really important things in an
architecture are the addressing model, e.g., flat byte addressed
little-endian, and the data formats, e.g., two's complement integers,
ASCII or UTF-8 text, IEEE floating point.  

Back in the day getting a program to act the same on different
computers, was really hard, with the switch from IBM 7090 (36 bit word
addressed binary floating point) to IBM 360 (32 or 64 bit byte
addressed hex floating point) the most famous example. These days we
write code and compile it for x64 or ARM or RISC-V and for the most
part, it just works because the data formats and addressing are all
the same.

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[sjenkin]

C wasn’t the first standardised coding language, FORTRAN & COBOL at least were before it,
so there were multi-platform source libraries and shared source, though often single platform.

From what I know, vendor extensions of FORTAN, optimised for their hardware, were common,
making high-performance, portable source difficult or impossible. 6-bit and 8-bit chars were the least of it.

Is this right:

	C was the first ’systems tool’ language + libraries available across many platforms.
	Notionally, source code could be ported with zero or minimal change.
	It made possible portable languages like PERL, PHP, Python.

	[ then came the "Tower of Babel" requiring tools like ‘autoconf’ ]

C became a bootstrapping environment for other portable languages & tools, e.g. C++ & Golang.

Secondly, portable systems tool languages with a common 2-part design
of parser/front-end providing an abstract syntax tree 
to multiple back-ends with platform specific code-generators.

Are these back-ends where most of the assembler, memory model and instruction optimisation take place now?


> On 6 Jul 2024, at 09:17, John Levine <johnl@taugh.com> wrote:
> 
> Back in the day getting a program to act the same on different
> computers, was really hard, with the switch from IBM 7090 (36 bit word
> addressed binary floating point) to IBM 360 (32 or 64 bit byte
> addressed hex floating point) the most famous example. These days we
> write code and compile it for x64 or ARM or RISC-V and for the most
> part, it just works because the data formats and addressing are all
> the same.


--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[John R Levine]

On Sat, 6 Jul 2024, sjenkin@canb.auug.org.au wrote:
> C wasn’t the first standardised coding language, FORTRAN & COBOL at least were before it,
> so there were multi-platform source libraries and shared source, though often single platform.
>
> From what I know, vendor extensions of FORTAN, optimised for their hardware, were common,
> making high-performance, portable source difficult or impossible. 6-bit and 8-bit chars were the least of it.

Even without vendor extensions, writing portable Fortran code was hard. 
Different floating point formats give you different results, and 
architectural differences can bite you.  One famous example is that the 
709x required word alignment, but S/360 had 4 byte aligned floats and 8 
byte aligned doubles, so this:

       REAL R(100)
       DOUBLE PRECISION D(10)
       EQUIVALENCE (R(2), D(1))

would work fine on a 7090 but crash on a 360.  That was painful enough 
that one of the first things they changed on S/370 was to allow misaligned 
data.

I never wrote much COBOL but it had structured data (the ancestor of C 
structs) and "redefines" for overlaying structures which could bite you 
when different machines had different size or alignment.  There were also 
a lot of different character sets which led to bugs when code had implicit 
assumptions about collating sequences, e.g., do numbers come before 
letters as in ASCII, or after as in EBCDIC.

The fact that everything now has 8 bit byte addressed memory with power of 
two data sizes and everything is ASCII makes all these problems go away.

> Is this right:
>
> 	C was the first ’systems tool’ language + libraries available across many platforms.
> 	Notionally, source code could be ported with zero or minimal change.
> 	It made possible portable languages like PERL, PHP, Python.

I think so.  There were previous system languages like a PL/I subset on 
Multics or PL/S on IBM or PL/M on micros but I don't think any of them had 
multiple targets.

> Secondly, portable systems tool languages with a common 2-part design
> of parser/front-end providing an abstract syntax tree
> to multiple back-ends with platform specific code-generators.
>
> Are these back-ends where most of the assembler, memory model and instruction optimisation take place now?

That's the standard way to build a compiler.  Back in the late 1950s 
someone had the bright idea to invent a common intermediate language they 
called UNCOL so all of the front ends could produce UNCOL and all of the 
back ends could translate from UNCOL thereby reducing the NxM compiler 
problem to N+M.  It never worked, both because the semantic differences 
between source languages are larger than they look, and the machine 
architectures of the era were wildly different.

Now we have GCC and LLVM which are sort of UNCOL-ish, but mostly because 
the back ends are all so similar.  The instruction sets may be different 
but the data formats are all the same.

R's,
John

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[Clem Cole]

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

On Sat, Jul 6, 2024 at 8:52 AM <sjenkin@canb.auug.org.au> wrote:

> Is this right:
>
>         C was the first ’systems tool’ language + libraries available
> across many platforms.
>
No !! Not even close.

ESPOL predators all of them, although one can say since it was only
available on Burroughs large, medium, and small systems - it was retargeted,
but not widely used.

Other systems programming languages followed, BCPL, BLISS, PL/360 and even
B before C. If you consider PL/M a child of PL/360 (which is was more than
child of PL/1 if you look at it), all of the others have code generators
and libraries for multiple ISA and OS and did before C did. That said, I
don't think any fo them have as many targets as C and many FORTRAN.

I might accept this rephrasing:

*While other systems' programming languages existed, and many were
retargets to multiple ISA/OS combinations, because of its appearance as a
language with a licensed but open implementation, at the time of the first
widespread available of inexpensive microprocessors, the language and it
libraries became (and continues to remain) the widest and most popular
systems development language in production use.*

WRT: FORTRAN.  John is correct; Kahan and his students demonstrated the
core problem with Paranoia ( https://www.netlib.org/paranoia/ ). But
remember that the FP issue was more than just a FORTRAN problem [BTW: I
took that class in those days].  You are correct that private extensions
were also a problem, although through F4 - the 'standard was IBM's 'G'
compiler, and while most vendors ensured they could pass the ANSI test
suite, smart vendors made sure they were IBM FORTRAN-G compliant. A good
example is the original Adventure game written on DEC's PDP-10 FORTRAN
compiler in the late 1970s, but it seemed to be running on anything a
FORTRAN compiler within weeks of its release on the ARPAnet [I know that my
peeps and I fed it to FORTRAN-G on TSS].

The same issue of "ANSI Standard" vs "De Facto Standard" occurred with F77,
but the de facto standard was VMS FORTRAN by that time    That said, by
F90, which is also post IEEE 754 [FP format] - portable FORTRAN code in the
wild was really not the issue it had been in the 60s and 70s.  FWIW: With
FORTRAN 2018, the compiler most people reference and for code that runs on
most supers is Intel's (DEC derived) ifort - but even Intel is replacing
that with their investment in IFX, the LLVM-based backend using Intel
rewritten (and FOSS) LLVM FORTRAN front end.

Clem

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

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[John R Levine]

On Sat, 6 Jul 2024, Clem Cole wrote:
> ESPOL predators all of them, although one can say since it was only
> available on Burroughs large, medium, and small systems - it was retargeted,
> but not widely used.

Good point.

> Other systems programming languages followed, BCPL, BLISS, PL/360 and even
> B before C. If you consider PL/M a child of PL/360 (which is was more than
> child of PL/1 if you look at it), all of the others have code generators
> and libraries for multiple ISA and OS and did before C did. That said, I
> don't think any fo them have as many targets as C and many FORTRAN.

Untangling the sequence of all this stuff is hard.  BCPL was indeed 
retargeted at a lot of machines but it's not clear how portable programs 
were since the word sizes varied so much from 16 to 60 bits, but couldn't 
deal with byte addressed memory which is a large reason we have C.

The original version of BLISS was only for the PDP-10.  DEC retargeted it 
to the PDP-11 and VAX, but I think that was after Unix moved to the 
Interdata and possibly other machines.

PL360 was Wirth's implentation language for Algol W, a 360 assembler with 
Algol-like syntax that had nothing to do with PL/I and only targeted the 
360.  I used it, it was pretty nice.

Are you maybe thinking of IBM's PL.8 or PL/S?  The former was originally 
for the 801, later S/360 and ROMP, the latter used for S/360 system 
programming.  PL.8 was about 80% of PL.I, hence the name, PL/S a subset 
with some hackery like register declarations and in-line assembler.

R's,
John

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[Charles H Sauer (he/him)]

On 7/6/2024 3:56 PM, John R Levine wrote:
> On Sat, 6 Jul 2024, Clem Cole wrote:
>> ESPOL predators all of them, although one can say since it was only
>> available on Burroughs large, medium, and small systems - it was 
>> retargeted,
>> but not widely used.
> 
> Good point.
> 
>> Other systems programming languages followed, BCPL, BLISS, PL/360 and 
>> even
>> B before C. If you consider PL/M a child of PL/360 (which is was more 
>> than
>> child of PL/1 if you look at it), all of the others have code generators
>> and libraries for multiple ISA and OS and did before C did. That said, I
>> don't think any fo them have as many targets as C and many FORTRAN.
> 
> Untangling the sequence of all this stuff is hard.  BCPL was indeed 
> retargeted at a lot of machines but it's not clear how portable programs 
> were since the word sizes varied so much from 16 to 60 bits, but 
> couldn't deal with byte addressed memory which is a large reason we have C.
> 
> The original version of BLISS was only for the PDP-10.  DEC retargeted 
> it to the PDP-11 and VAX, but I think that was after Unix moved to the 
> Interdata and possibly other machines.
> 
> PL360 was Wirth's implentation language for Algol W, a 360 assembler 
> with Algol-like syntax that had nothing to do with PL/I and only 
> targeted the 360.  I used it, it was pretty nice.
> 
> Are you maybe thinking of IBM's PL.8 or PL/S?  The former was originally 
> for the 801, later S/360 and ROMP, the latter used for S/360 system 
> programming.  PL.8 was about 80% of PL.I, hence the name, PL/S a subset 
> with some hackery like register declarations and in-line assembler.
> 
> R's,
> John

I like the 80% explanation, but suspect PL.8 was really named PL.8 to go 
along with the 801 processor architecture defined in Building 801 aka 
Thomas J. Watson Research Center in Yorktown Heights. There are probably 
living Yorktown alumni that could be definitive.

I found PL/I quite usable as long as one kept it simple. But then, I 
also found Fortran usable as long as one kept it simple. Regarding 
Fortran portability, I did all my dissertation work on punched cards 
using CDC Fortran on the 6400/6600 at the UT-Austin computation center. 
I brought several boxes of cards to Yorktown and don't remember any 
significant difficulty getting my simulator and other programs to run on 
VM/370 there. The absence of pointers and structures in Fortran was 
annoying. Eventually I used SNOBOL to quickly translate the Fortran to 
PL/I (https://technologists.com/sauer/RESQPPP.pdf).

Charlie

-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/LinkedIn/Twitter: CharlesHSauer

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[Peter Yardley]

There was a ‘military’ standard ForTran 66. It was more difficult to use than the various ForTran IVs, which had several niceties like string literals, but the code was at least more portable. This was about 40 years ago so details are fading.

> On 7 Jul 2024, at 7:32 AM, Charles H Sauer (he/him) <sauer@technologists.com> wrote:
> 
> 
> 
> On 7/6/2024 3:56 PM, John R Levine wrote:
>> On Sat, 6 Jul 2024, Clem Cole wrote:
>>> ESPOL predators all of them, although one can say since it was only
>>> available on Burroughs large, medium, and small systems - it was retargeted,
>>> but not widely used.
>> Good point.
>>> Other systems programming languages followed, BCPL, BLISS, PL/360 and even
>>> B before C. If you consider PL/M a child of PL/360 (which is was more than
>>> child of PL/1 if you look at it), all of the others have code generators
>>> and libraries for multiple ISA and OS and did before C did. That said, I
>>> don't think any fo them have as many targets as C and many FORTRAN.
>> Untangling the sequence of all this stuff is hard.  BCPL was indeed retargeted at a lot of machines but it's not clear how portable programs were since the word sizes varied so much from 16 to 60 bits, but couldn't deal with byte addressed memory which is a large reason we have C.
>> The original version of BLISS was only for the PDP-10.  DEC retargeted it to the PDP-11 and VAX, but I think that was after Unix moved to the Interdata and possibly other machines.
>> PL360 was Wirth's implentation language for Algol W, a 360 assembler with Algol-like syntax that had nothing to do with PL/I and only targeted the 360.  I used it, it was pretty nice.
>> Are you maybe thinking of IBM's PL.8 or PL/S?  The former was originally for the 801, later S/360 and ROMP, the latter used for S/360 system programming.  PL.8 was about 80% of PL.I, hence the name, PL/S a subset with some hackery like register declarations and in-line assembler.
>> R's,
>> John
> 
> I like the 80% explanation, but suspect PL.8 was really named PL.8 to go along with the 801 processor architecture defined in Building 801 aka Thomas J. Watson Research Center in Yorktown Heights. There are probably living Yorktown alumni that could be definitive.
> 
> I found PL/I quite usable as long as one kept it simple. But then, I also found Fortran usable as long as one kept it simple. Regarding Fortran portability, I did all my dissertation work on punched cards using CDC Fortran on the 6400/6600 at the UT-Austin computation center. I brought several boxes of cards to Yorktown and don't remember any significant difficulty getting my simulator and other programs to run on VM/370 there. The absence of pointers and structures in Fortran was annoying. Eventually I used SNOBOL to quickly translate the Fortran to PL/I (https://technologists.com/sauer/RESQPPP.pdf).
> 
> Charlie
> 
> -- 
> voice: +1.512.784.7526       e-mail: sauer@technologists.com
> fax: +1.512.346.5240         Web: https://technologists.com/sauer/
> Facebook/Google/LinkedIn/Twitter: CharlesHSauer

Peter Yardley
peter.martin.yardley@gmail.com

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[James Frew]

On 2024-07-06 16:46, Peter Yardley wrote:
> There was a ‘military’ standard ForTran 66. It was more difficult to use than the various ForTran IVs, which had several niceties like string literals, but the code was at least more portable. This was about 40 years ago so details are fading.

https://apps.dtic.mil/sti/tr/pdf/ADA328606.pdf

Not the actual standard, but the single most useful reference on porting 
old FORTRAN.

 From the Foreword:

"This FORTRAN volume presents material that will assist in understanding 
FORTRAN 66 and its replacement, FORTRAN 77. Because even a superficial 
comparison of the two language variants will involve contrasting their 
respective syntaxes, a set of FORTRAN 66 grammar rules is included: 
These rules, expressed in chart form, are comparable to rules that 
define FORTRAN 77. Next, there are two chapters of observations on what 
using standard FORTRAN 66 implies, and how the 1966 Standard is often 
interpreted and stretched to achieve practical ends. Finally, a 
comparison of the new FORTRAN 77 with FORTRAN 66 shows how the language 
has changed, and what converting older programs must entail. The four 
chapters address programmers concerned with FORTRAN conversions, 
managers engaged in programming standards, and other practitioners 
interested in system influences upon languages. Since the text touches 
upon several general programming aspects (input/output, storage 
allocation and lifetimes, control structures), the volume's appeal will 
extend beyond the immediate FORTRAN community."

Cheers,
/Frew

P.S.: If anybody cares, I have a cleaner scan that I can share.

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[John Levine]

It appears that Charles H Sauer (he/him) <sauer@technologists.com> said:
>I like the 80% explanation, but suspect PL.8 was really named PL.8 to go 
>along with the 801 processor architecture defined in Building 801 aka 
>Thomas J. Watson Research Center in Yorktown Heights. There are probably 
>living Yorktown alumni that could be definitive.

John Cocke said in a paper in IBM J R&D V44 #1/2, Jan 2000, p 50:

 The result [of the language design] was the PL.8 language, the
 ".8" implying that it had about 80% of the richness of PL/I.
 PL.8 bore the same relation to PL/I as the 801 architecture
 had to System/370.

Not gonna argue with him.

>I found PL/I quite usable as long as one kept it simple. But then, I 
>also found Fortran usable as long as one kept it simple. Regarding 
>Fortran portability, I did all my dissertation work on punched cards 
>using CDC Fortran on the 6400/6600 at the UT-Austin computation center. 
>I brought several boxes of cards to Yorktown and don't remember any 
>significant difficulty getting my simulator and other programs to run on 
>VM/370 there. The absence of pointers and structures in Fortran was 
>annoying. Eventually I used SNOBOL to quickly translate the Fortran to 
>PL/I (https://technologists.com/sauer/RESQPPP.pdf).

For the most part Fortran could be pretty portable.  The hard parts 
were when you were trying to get reliable numeric results in complex
calculations, or you were doing stuff that Fortran didn't do very
well like pre-F77 string handling.

R's,
JOhn

[TUHS] Re: PL.8 [was Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[Charles H Sauer (he/him)]

On 7/6/2024 8:39 PM, John Levine wrote:
> It appears that Charles H Sauer (he/him) <sauer@technologists.com> said:
>> I like the 80% explanation, but suspect PL.8 was really named PL.8 to go
>> along with the 801 processor architecture defined in Building 801 aka
>> Thomas J. Watson Research Center in Yorktown Heights. There are probably
>> living Yorktown alumni that could be definitive.
> 
> John Cocke said in a paper in IBM J R&D V44 #1/2, Jan 2000, p 50:
> 
>   The result [of the language design] was the PL.8 language, the
>   ".8" implying that it had about 80% of the richness of PL/I.
>   PL.8 bore the same relation to PL/I as the 801 architecture
>   had to System/370.
> 
> Not gonna argue with him.

John C isn't around to say one way or the other. Perhaps he really did 
say that, but ...
o That paper seems to be a reprint of the 1990 IBM J R&D V34 paper
o I suspect co-author Vicky wrote 80% of the paper and wrote the 80% 
sentence. (I had substantial contact with Vicky at IBM. She and Peter 
became my neighbors for a while after I left IBM. Peter was also a judge 
at cat shows and I would see him at those.)
o Marc Auslander and Marty Hopkins seemed to be the driving forces 
behind the PL.8 compiler and language. I think their June 1982 "An 
Overview of the PL.8 Compiler" SIGPLAN Notices 17 (6) was the first 
external notice of the compiler and language.
o Radin's 1976 "The 801 minicomputer" eventually appeared externally in 
March 1982 SIGPLAN Notices 17 (4). That paper refers to the "801 
compiler" and alludes to differences from PL/I that typified PL.8, e.g., 
offsets vs. pointers, but doesn't name the language.
o ".8" implying 80% of the richness of PL/I sounds revisionist

Far afield from TUHS...

Charlie
-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/LinkedIn/Twitter: CharlesHSauer

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[arnold]

"John Levine" <johnl@taugh.com> wrote:

> These days we write code and compile it for x64 or ARM or RISC-V and
> for the most part, it just works because the data formats and addressing
> are all the same.

I have to agree with this. My experience is that for most[1] user level
code, the architecture simply doesn't matter. I started working on gawk
on vaxen, moved to MC68010, then to Sparc, then to 32-bit x86, then to
64-bit x86, with a side segue to 32-bit PPC.  Other people compile it
on everything else: ARM, S/390, Alpha, Itanium, RISC-V, you name it. OS
differences matter more than architecutre differences.

This list's membership is heavily weighted with compiler writers and
OS porters, which is fine, but that's a very small percentage of the
number of people out in the world writing code. Those folks (including
me in my $DAYJOB) all work in C++, Java, Python, Rust, and Go, and the
architecture simply doesn't matter to them. (C# is nominally portable
as well, but hasn't caught on outside of Windows like the others.)

I *do* think that studying a nice architecture, like the PDP-11,
is important for people learning software development. In college I
took data structures and algorithms together with PDP-11 assembler,
and it was only when I saw how recursion worked in assembler with
the stack that I finally understood it. It was a real epiphany.

My two cents,

Arnold

[1] Architecture does come into play if you're writing _binary_
data, which is why RPC/XDR were invented for NFS and why Google
has it's RPC language and libraries.

[TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?

[Dan Cross]

On Fri, Jul 5, 2024 at 5:47 PM John Levine <johnl@taugh.com> wrote:
> It appears that Peter Yardley <peter.martin.yardley@gmail.com> said:
> >The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, program counter, status register. No stack register tho. There was a micro processor version by Fairchild.
>
> It did, but it was word addressed which makes it an historical
> curiosity like its spiritual predecessors PDP-4/5/7/8/9.
>
> I also have a mental model of a PDP-11 but these days it's more a simplified 386
> leaving out the dumb or useless stuff.  I ignore the segments which are useless
> other than for 286 emulation, and some of the strange instructions like decimal
> adjust and the warty 8 and 16 bit registers.
>
> What's important is the memory model which on a 386 the way it was
> invariably set up was a flat 32 bit consistent little-endian byte
> addressed memory with a stack and reasonable addressing modes, and 4K
> pages for virtual memory.

It is important to ask, "what does one want to learn about
architecture by going through this study exercise?"  If one just wants
to study the unprivileged instruction set at the level of assembler
mnemonics, then x86_64 isn't completely awful.  Some of the registers
are oddly named, and some instructions have odd implicit operands
(e.g., `inc %rax`, but if you're just looking at assembler syntax,
perhaps one doesn't care.  Of course, the instruction encoding is a
huge mess, but most work-a-day programmers don't have to care about
that.

Where it gets really ugly, in my opinion, is in the privileged
instruction set, and there you can't get away from history: there's no
escaping descriptor tables or segmentation there! The interrupt stack
table in the TSS must be set up properly or you're bound for a triple
fault.  This implies the GDT, IDT, TR, and TSS --- all 286-era goo ---
are all properly set up, and you can't get away from that stuff, even
in a modern operating system (you have to reload the TSS _or_ replace
RSP0 on every thread switch: there's no other way; that's just how the
hardware works). And then there's the matter that you _have_ to enable
paging before switching into 64-bit mode on x86...it's not hard, but
it's annoying (and the x86S proposal doubles down on it).  It'd be
more rational to allow execution against a flat 64-bit physical
address space; for x86S, I'd rather be able to specify a reset vector
in the physical address space by some sort of external strap.

Both RISC-V and ARM seem much more rational in this world by comparison.

I don't like the RISC-V page table format, though: it doesn't permit
you to pun the root of the paging radix tree for other levels, meaning
you can't use the "recursive page table" trick to get access to page
tables themselves: this, in turn, has effects on the rest of the
design of a virtual memory system.  I think I've found a way around
that involving a dedicated temporary mapping region, but it's kind of
a pain and takes a non-trivial chunk of virtual address _space_ (if
not fully realized memory) that I don't care for.  How to handle
cached vs uncached mappings, e.g., for MMIO, is still a bit mysterious
to me.  Honestly, this is something that x86 got largely right.

ARM is ok, but has grown a lot of complexity; most of which can be
ignored until needed, I suspect; saturating arithmetic, for example.
Understanding it is not critical to understanding more or less how the
computer works.

> ARM should be OK too but I have to ask which ARM? There have been so
> many generations often not backward compatible.

I'd start with ARMv8 at this point.  It has less confusing, more
rational stack push/pop semantics and I think they did away with the
conditional execution stuff, which is easier to reason about.

My 2c.

        - Dan C.

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Dave Horsfall]

On Fri, 5 Jul 2024, Peter Yardley wrote:

> The DG Nova had a pretty nice architecture. 2 accumulators, 2 index 
> registers, program counter, status register. No stack register tho. 
> There was a micro processor version by Fairchild.

The story behind it is interesting too.  The designer at DEC (Ed de 
Castro) tried to promote it, Ken Olson didn't like it, so he left to form 
Data General and created the DG Nova.

OK, not a Unix box...

-- Dave

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Brad Spencer]

Dave Horsfall <dave@horsfall.org> writes:

> On Fri, 5 Jul 2024, Peter Yardley wrote:
>
>> The DG Nova had a pretty nice architecture. 2 accumulators, 2 index 
>> registers, program counter, status register. No stack register tho. 
>> There was a micro processor version by Fairchild.
>
> The story behind it is interesting too.  The designer at DEC (Ed de 
> Castro) tried to promote it, Ken Olson didn't like it, so he left to form 
> Data General and created the DG Nova.
>
> OK, not a Unix box...
>
> -- Dave




I believe AOS for the Nova... and AOS/VS for the Supernova, aka the MV
series.  I got very good at dealing with AOS/VS at a university I
attended.  The later MV/xxxxx Supernova boxes could run Unix, I
believe... (at least I remember the university running Unix on a MV
series after I left).



-- 
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Dave Horsfall]

On Sun, 7 Jul 2024, Brad Spencer wrote:

> I believe AOS for the Nova... and AOS/VS for the Supernova, aka the MV 
> series.  I got very good at dealing with AOS/VS at a university I 
> attended.  The later MV/xxxxx Supernova boxes could run Unix, I 
> believe... (at least I remember the university running Unix on a MV 
> series after I left).

Ah yes, I remember hearing of Unix on the MV series, but never actually 
saw one.  Looks like a neat machine.

-- Dave (vk2kfu)

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Lars Brinkhoff]

Brad Spencer wrote:
> I believe AOS for the Nova... and AOS/VS for the Supernova, aka the MV
> series.

I believe the Supernova was an early and faster implementation of the
regular Nova.  A newer generation, still 16-bit, was called Eclipse.  MV
was the ("NO MODE BIT!") 32-bit generation.  Or something like that.  DG
then bet on the short-lived Motorola 88000 with a series called the
AViiON ("NOVA ii"?).

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Dave Horsfall]

On Mon, 8 Jul 2024, Lars Brinkhoff wrote:

> I believe the Supernova was an early and faster implementation of the 
> regular Nova.  A newer generation, still 16-bit, was called Eclipse.  
> MV was the ("NO MODE BIT!") 32-bit generation.  Or something like that.  
> DG then bet on the short-lived Motorola 88000 with a series called the 
> AViiON ("NOVA ii"?).

I'd never thought about that derivation!

-- Dave

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[David Arnold]

> On 8 Jul 2024, at 17:36, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Mon, 8 Jul 2024, Lars Brinkhoff wrote:
>> 
>> DG then bet on the short-lived Motorola 88000 with a series called the 
>> AViiON ("NOVA ii"?).
> 
> I'd never thought about that derivation!

I wonder if it could extend to the CLARiiON storage arrays as well?



d

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[arnold]

Brad Spencer <brad@anduin.eldar.org> wrote:

> The later MV/xxxxx Supernova boxes could run Unix, I
> believe... (at least I remember the university running Unix on a MV
> series after I left).

I think these were called "Eclipse", and the story of their
development is told in the famous book "The Soul of a New Machine".
For you youngsters out there, it's a great read.

We had one at Georgia Tech, it ran a Unix emulation on top
of AOS (or whatever it was called). Later on DG ported Unix to
run on it native.

Arnold

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Larry McVoy]

On Mon, Jul 08, 2024 at 12:59:14AM -0600, arnold@skeeve.com wrote:
> Brad Spencer <brad@anduin.eldar.org> wrote:
> 
> > The later MV/xxxxx Supernova boxes could run Unix, I
> > believe... (at least I remember the university running Unix on a MV
> > series after I left).
> 
> I think these were called "Eclipse", and the story of their
> development is told in the famous book "The Soul of a New Machine".
> For you youngsters out there, it's a great read.
> 
> We had one at Georgia Tech, it ran a Unix emulation on top
> of AOS (or whatever it was called). Later on DG ported Unix to
> run on it native.

I've heard, but never verified, that they did a really nice SMP Unix.
If anyone has seen the code I'd like to hear what you thought.  The
way it was described to me, it sounded like an SMP SunOS.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Al Kossow]

>> I think these were called "Eclipse"

Eclipse is a 16 bit system that predates the MV

see http://bitsavers.org/pdf/dg/eclipse  .ca 1974
as opposed to
mv4000 mv8000 (ca. 1980) mv10000

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Tom Lyon]

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

Here's a scan of the DG Eclipse MV-8000 Product Summary. Fairly detailed.
https://drive.google.com/file/d/1SqvetITVo4mRp8vLB0pU2p8hZT6tXW5z/view?usp=sharing

On Mon, Jul 8, 2024 at 8:37 AM Al Kossow <aek@bitsavers.org> wrote:

>
> >> I think these were called "Eclipse"
>
> Eclipse is a 16 bit system that predates the MV
>
> see http://bitsavers.org/pdf/dg/eclipse  .ca 1974
> as opposed to
> mv4000 mv8000 (ca. 1980) mv10000
>

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Clem Cole]

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

Al is right. Tom West led the Eagle project in Westboro, MA, which is
documented in the Soul of the New Machine. The Eagle project became the
32-bit MV/8000 Eclipse [see https://en.wikipedia.org/wiki/Data_General for
more details].   I knew a few of the HW guys, as I went to CMU with one of
them, and a couple of them came to do the Stellar CPU a few years later.
But I did not know the SW folks there like I know the DEC folks,
particularly since I never worked there.

That said, WRT to their later UNIX box, I did have access to the same at
Locus.  As we did a lot of work for DG, adding features and helping them
with POSIX/FIPS and SPEC1170 conformance — IIRC, we added the FS Switch for
NFS support.  It was probably the easiest UNIX kernel I have ever worked
with, with the shortest learning curve. I may remember that the User API
was based on SVR3/SVID, which means >>IIRC<<; it was based on Streams/TLI,
but ISTR is a user mode sockets layer for porting (but I'm not sure of that
-- it has been almost 30 years now).    The kernel itself was a scratch
rewrite with SMP in mind. The locking scheme was clean and simple and
worked well to order 32/64 processors in our tests.  Moreover, the kernel
was well-documented. I do not know for sure, but I remember being told by
some of the DG folks in NC that it was originally planned for the failed
Fountainhead system, which was canceled after West and the MA-based folks
delivered Eagle before the new system came from DG NC.

Also, I believe that DG had in response to BLISS a low-level system
language they called PL/N, but I don't know much about it/I never saw it -
I'm told that it was a >>very<< subset PL/1 syntax, but like PL/360 -
exposed a lot of hardware.  ISTR that they developed some MV series
compilers with it, but since Eagle was a 32-bit super set of Nova, AOS was
ported.  FWIW:. Since Multics had used PL/1 and supposedly Fountainhead was
heavily influenced by Multics (as was Pr1me, by the way), it would not
surprise me that PL/n has a PL/1 'flavor.'

I'd love to know for sure >>but my WAG<< is that that core work for
Fountainhead was reimplemented in C for their SMP 88000 box, and they added
a UNIX API layer to it.


ᐧ

On Mon, Jul 8, 2024 at 9:22 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Mon, Jul 08, 2024 at 12:59:14AM -0600, arnold@skeeve.com wrote:
> > Brad Spencer <brad@anduin.eldar.org> wrote:
> >
> > > The later MV/xxxxx Supernova boxes could run Unix, I
> > > believe... (at least I remember the university running Unix on a MV
> > > series after I left).
> >
> > I think these were called "Eclipse", and the story of their
> > development is told in the famous book "The Soul of a New Machine".
> > For you youngsters out there, it's a great read.
> >
> > We had one at Georgia Tech, it ran a Unix emulation on top
> > of AOS (or whatever it was called). Later on DG ported Unix to
> > run on it native.
>
> I've heard, but never verified, that they did a really nice SMP Unix.
> If anyone has seen the code I'd like to hear what you thought.  The
> way it was described to me, it sounded like an SMP SunOS.
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Brad Spencer]

arnold@skeeve.com writes:

> Brad Spencer <brad@anduin.eldar.org> wrote:
>
>> The later MV/xxxxx Supernova boxes could run Unix, I
>> believe... (at least I remember the university running Unix on a MV
>> series after I left).
>
> I think these were called "Eclipse", and the story of their
> development is told in the famous book "The Soul of a New Machine".
> For you youngsters out there, it's a great read.

Ya, that is right...  I didn't remember that correctly.  The Eclipse was
the MV series, 32 bit, and ran AOS/VS, the Nova, 16 bit, ran AOS.

> We had one at Georgia Tech, it ran a Unix emulation on top
> of AOS (or whatever it was called). Later on DG ported Unix to
> run on it native.

I was there for the start of that emulation layer stuff for AOS/VS.
When I encountered it, it was just, mostly, something that helped port
software written for Unix to AOS/VS.  I remember two things that made
that very hard, the lack of any sort of fork() notion in AOS/VS and the
lack of any sort of setuid() notion.  You pretty much couldn't do either
of those in any manor.  There was an idea much like fork()+exec() that
could be used to start a new program, but that required source changes.
I very much remember a port of sendmail that couldn't be used to deliver
mail to a local user on the box because you didn't have setuid() and
couldn't fake it as a normal user.  It was nice to hear that DG did a
real Unix port, but that was after my time.

> Arnold



-- 
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Al Kossow]

> I was there for the start of that emulation layer stuff for AOS/VS.

I think this has been asked before, but does anyone have the Portable
Operating System Pascal sources that were done there?

This isn't the same as the portable tools stuff that started out in
the Prentice-Hall book and shows up on DECUS tapes.

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[John Levine]

According to Dave Horsfall <dave@horsfall.org>:
>On Fri, 5 Jul 2024, Peter Yardley wrote:
>
>> The DG Nova had a pretty nice architecture. 2 accumulators, 2 index 
>> registers, program counter, status register. No stack register tho. 
>> There was a micro processor version by Fairchild.
>
>The story behind it is interesting too.  The designer at DEC (Ed de 
>Castro) tried to promote it, Ken Olson didn't like it, so he left to form 
>Data General and created the DG Nova.

That's the folklore but the reality is somewhat more nuanced than that.

He was working on PDP-X, a 16 bit word addressed line of machines in
the style of the PDP-8 and -9:

https://bitsavers.org/pdf/dec/pdp-x/29_Nov67.pdf

When management decided to build the PDP-11, de Castro did indeed quit
and started DG, but the Nova was quite different from the PDP-X. It
was a clever design that used new MSI chips so the processor fit on
one board and was, I assume, pretty cheap to build.
-- 
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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Dave Horsfall]

On Mon, 8 Jul 2024, John Levine wrote:

[...]

> When management decided to build the PDP-11, de Castro did indeed quit 
> and started DG, but the Nova was quite different from the PDP-X. It was 
> a clever design that used new MSI chips so the processor fit on one 
> board and was, I assume, pretty cheap to build.

Thanks for the clarification.

-- Dave

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Peter Yardley]

Just a recollection …

Our department sold our Nova to the Navy (RAN) as part of a programming course on Novas and microcomputers. The Navy still used the Novas as gunnery computers, possibly amongst things, ours was going to be used for training. It had core memory, which was an advantage in the turrets of the frigates (hard drives of the time didn’t survive the shock). One of my colleagues used to fix the core memory using a magnifying loupe and a fine soldering iron.

We had Algol, ForTran and 8080 and 6502 cross assemblers amongst other things. There was a 16 user editor and you had to line up on the system console to be able to do a compilation (we were running a foreground/background OS, it was a pretty small system). We all used the same directory and had to name our files with our initials.
 
> On 8 Jul 2024, at 8:00 AM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Fri, 5 Jul 2024, Peter Yardley wrote:
> 
>> The DG Nova had a pretty nice architecture. 2 accumulators, 2 index 
>> registers, program counter, status register. No stack register tho. 
>> There was a micro processor version by Fairchild.
> 
> The story behind it is interesting too.  The designer at DEC (Ed de 
> Castro) tried to promote it, Ken Olson didn't like it, so he left to form 
> Data General and created the DG Nova.
> 
> OK, not a Unix box...
> 
> -- Dave

.1.3.6.1.4.1.8852.4.2
Peter Yardley
peter.martin.yardley@gmail.com

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Jon Steinhart]

Dave Horsfall writes:
> Was it John Gilmore who said "Segment registers are for worms"?

Being as John is in my kitchen making breakfast at the moment, the answer is "no" :-)

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Dave Horsfall]

On Fri, 5 Jul 2024, Jon Steinhart wrote:

> Dave Horsfall writes:
> > Was it John Gilmore who said "Segment registers are for worms"?
> 
> Being as John is in my kitchen making breakfast at the moment, the 
> answer is "no" :-)

Hmmm...  I guess it was either RMS or DJB then (not that I'm equating all 
of them of course).

-- Dave

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Marc Rochkind]

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

On Thu, Jul 4, 2024 at 2:24 AM Vincenzo Nicosia <katolaz@freaknet.org>
wrote:

> Maybe that's because I cannot find anything
> romantic or poetic in "financing, regulatory constraints, product
> schedules, commitments, staffing issues, and everything else that isn't
> coding".
>

 I'm with you there. That's why they call it "work."

Marc

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

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[John Levine]

According to  <sjenkin@canb.auug.org.au>:
>Developers of Initial Unix arguably were 10x-100x more productive than IBM OS/360, a ‘best practice’ development at the time,
>so what CSRC did differently is worth close examination.

Ken Thompson was an astonishingly productive programmer. I don't think
you can build a business plan that starts with "hire someone like
Ken."

One weekend just for fun he pounded out most of an APL interpreter,
which I then took and spent a month part time adding a few features
like saving and loading workspaces, and adjusting it to use the APL
character set on our funky bitmap terminals at Yale. He did more in
the weekend than I did in the month, and I am not a terrible
programmer.

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[segaloco via TUHS]

On Wednesday, July 3rd, 2024 at 6:53 PM, John Levine <johnl@taugh.com> wrote:

> According to sjenkin@canb.auug.org.au:
> 
> > Developers of Initial Unix arguably were 10x-100x more productive than IBM OS/360, a ‘best practice’ development at the time,
> > so what CSRC did differently is worth close examination.
> 
> 
> Ken Thompson was an astonishingly productive programmer. I don't think
> you can build a business plan that starts with "hire someone like
> Ken."
> 
> One weekend just for fun he pounded out most of an APL interpreter,
> which I then took and spent a month part time adding a few features
> like saving and loading workspaces, and adjusting it to use the APL
> character set on our funky bitmap terminals at Yale. He did more in
> the weekend than I did in the month, and I am not a terrible
> programmer.

To add to the praise, Ken, yourself, and others weren't exactly working on modern 115200 baud terminal emulators and IDEs with all the fancy modern tab completion and automatic linting either.  History has given me an appreciation that these sorts of conveniences work at all.  If I'm ever having a really bad day with my tools, I just think about Ken, Dennis, et. al. hammering away at 33 ASRs making legends happen and suddenly I don't feel so bad.

- Matt G.

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Rob Pike]

I liked working with Ken.

One fond memory was porting Plan 9 to the SPARC over Christmas break.
People went home, we hacked, Bonnie brought us food. A week later
people came back and we had a new architecture up and running, pretty
much in toto. (The way the system worked made this a joy to do - so
much just worked right away, including for example the ps command.)

One whole day of that was dealing with register windows, which brought
nothing to the table but trouble, and forced us to use R1 as the stack
pointer register. That was not the fondest day.

Architecture people: please just let me pretend your CPU is like a
PDP-11. No surprises, OK? I'll handle the complaints about irrelevance
in the modern age.

-rob


On Thu, Jul 4, 2024 at 12:59 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>
> On Wednesday, July 3rd, 2024 at 6:53 PM, John Levine <johnl@taugh.com> wrote:
>
> > According to sjenkin@canb.auug.org.au:
> >
> > > Developers of Initial Unix arguably were 10x-100x more productive than IBM OS/360, a ‘best practice’ development at the time,
> > > so what CSRC did differently is worth close examination.
> >
> >
> > Ken Thompson was an astonishingly productive programmer. I don't think
> > you can build a business plan that starts with "hire someone like
> > Ken."
> >
> > One weekend just for fun he pounded out most of an APL interpreter,
> > which I then took and spent a month part time adding a few features
> > like saving and loading workspaces, and adjusting it to use the APL
> > character set on our funky bitmap terminals at Yale. He did more in
> > the weekend than I did in the month, and I am not a terrible
> > programmer.
>
> To add to the praise, Ken, yourself, and others weren't exactly working on modern 115200 baud terminal emulators and IDEs with all the fancy modern tab completion and automatic linting either.  History has given me an appreciation that these sorts of conveniences work at all.  If I'm ever having a really bad day with my tools, I just think about Ken, Dennis, et. al. hammering away at 33 ASRs making legends happen and suddenly I don't feel so bad.
>
> - Matt G.

[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

[Larry McVoy]

On Thu, Jul 04, 2024 at 04:53:17PM +1000, Rob Pike wrote:
> Architecture people: please just let me pretend your CPU is like a
> PDP-11. No surprises, OK? I'll handle the complaints about irrelevance
> in the modern age.

Funny you should say that.  My kid is learning how to code and I told 
him to learn PDP-11 (or these days, probably ARM if that isn't all
messed up) and then pretend that everything works like that.  It's
a fine mental model.  Trying to develop that mental model in the
chaos that is x86_64, I'm not sure that is even possible.  It would
take a long time.  I think you can learn a PDP-11, as a newbie, in
a month or two.  

So +1 for what Rob said.

[TUHS] Anyone ever heard of teaching a case study of Initial Unix?

[Norman Wilson]

Steve Jenkin:

   I've never heard of a Computer Science or Software Engineering program
   that included a `case study' component, especially for Software
   Development & Projects.

[...]

  Creating Unix V6, because it profoundly changed computing & development,
  would seem an obvious Case Study for many aspects of Software, Coding
  and Projects.

====

How about the course for which John Lions wrote his famous
exegesis of the 6/e kernel?

Norman Wilson
Toronto ON