From jnc at mercury.lcs.mit.edu  Sun Jun  1 00:19:14 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 31 May 2014 10:19:14 -0400 (EDT)
Subject: [TUHS] Bugs in V6 'dcheck'
Message-ID: <20140531141914.BB15818C0CA@mercury.lcs.mit.edu>

    > From: Ronald Natalie <ron at ronnatalie.com>

    > If I understand what you are saying, it only occurs when you run dcheck
    > with mutliple volumes at one time?

Right, _both_ bugs have that characteristic. But the first one (the
fence-post) only happens in very particular circumstances; the second (the
un-initialized variable) should have happened every time.


    > From: norman at oclsc.org (Norman Wilson)

    > To me it's not surprising at all.
    > On one hand, current examples of widely-distributed critical code
    > containing serious flaws are legion.

What astonished me was not that there was a bug (which I can easily believe),
but that it was one that would have happened _every time they ran it_.

'dcheck' has this list of disks compiled into it. (Oh, BTW, my fixed version
now reads a file, /etc/disks; I am running a number of simulated machines,
and the compiled-in table was a pain.)

So I would have thought they must have at least tried that mode of operation
once? And running it that way just once should have shown the bug. Or did
they try it, see the bug, and 'dealt' with it by just never running it that
way?

	Noel


From jnc at mercury.lcs.mit.edu  Sun Jun  1 01:55:27 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 31 May 2014 11:55:27 -0400 (EDT)
Subject: [TUHS] Bugs in V6 'dcheck'
Message-ID: <20140531155527.39A3B18C09C@mercury.lcs.mit.edu>

    > From: jnc at mercury.lcs.mit.edu (Noel Chiappa)

    > the second (the un-initialized variable) should have happened every
    > time.

OK, so I was wrong! The variable in question was a global static, 'ino' (the
current inode number), so the answer isn't something simple like 'it was an
auto that happened to be cleared for each disk'. But now that I look closely,
I think I see a way it might have worked.


'dcheck' is a two-pass per disk thing: it begins each disk by clearing its
'inode link count' table; then the first pass does a pass over all the inodes,
and for ones that are directories, increments counts for all the entries; the
second pass re-scans all the inodes, and makes sure that the link count in the
inode itself matches the computed count in the table.

'ino' was cleared before the _second_ pass, but not the _first_. So it was
zero for the first pass of the first disk, but non-zero for the first pass on
the second disk.

This looks like the kind of bug that should almost always be fatal, right?
That's what I thought at first... (and I tried the original version on one of
my machines to make sure it did fail). But...


The loop in each pass has two index variables, one of which is 'ino', which it
compares with the maximum inode number for that disk (per the super-block),
and bails if it reaches the max:

	      for(i=0; ino<nfiles; i =+ NIBLK)

If the first disk is _larger_ than the second, the first pass will never
execute at all for the second desk (producing errors).

However, if the _second_ is larger, then the second disk's first pass will in
fact examine the starting (nfilesSUBsecond - nfilesSUBfirst) inodes of the
second disk to see if they are directories (and if so, count their links).

So if the last nfilesSUBfirst inodes of the second disk are empty (which is
often the case with large drives - I had modified 'df' to count the free
inodes as well as disk blocks, and after doing so I noticed that Unix seems to
be quite generous in its default inode allocations), it will in fact work!

The fact that 'ino' is wrong all throughout the first pass of the second disk
(it counts up from nfilesSUBfirst to nfilesSUBsecond) turns out to be
harmless, because the first pass never uses the current inode number, it only
looks at the inode numbers in the directories.


Note that with two disks of _equal size_, it fails. Only if the second is
larger does it work! (And this generalizes out to N disks - as long as each
one is enough larger than the one before!) So for the config they were
running (rk2, dp0) it probably did in fact work!

   Noel


From cowan at mercury.ccil.org  Sun Jun  1 02:03:02 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Sat, 31 May 2014 12:03:02 -0400
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <20140531133051.5F2531DE37F@lignose.oclsc.org>
References: <20140531133051.5F2531DE37F@lignose.oclsc.org>
Message-ID: <20140531160302.GB371@mercury.ccil.org>

Norman Wilson scripsit:

> (To me, anyway.  Back in the 1980s, when I was at Bell Labs,
> SP&E published a paper by Don Knuth discussing all the many
> bugs found in TeX, including some statistical analysis.  I
> thought it fascinating and revealing and think reading it
> made me a better programmer.  Rob Pike thought it was terribly
> boring and shouldn't have been published.  Decidedly different
> viewpoints.)

I agree that "The Errors of TeX" was an excellent article.  Mr. Pike is
well-known to be, mmmm, easily bored.  On the other hand, his sense of
humor isn't to everyone's taste, either.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Even the best of friends cannot attend each others' funeral.
        --Kehlog Albran, The Profit


From ron at ronnatalie.com  Sun Jun  1 02:18:06 2014
From: ron at ronnatalie.com (Ron Natalie)
Date: Sat, 31 May 2014 12:18:06 -0400
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <20140531155527.39A3B18C09C@mercury.lcs.mit.edu>
References: <20140531155527.39A3B18C09C@mercury.lcs.mit.edu>
Message-ID: <006001cf7ceb$e81ac120$b8504360$@ronnatalie.com>

>   OK, so I was wrong! The variable in question was a global static, 'ino'
(the current inode number),

Static is a much overloaded word in C, it's just a global variable.


> 'ino' was cleared before the _second_ pass, but not the _first_. So it was
zero for the first pass of the first disk, but non-zero for the first pass
on the second disk.

Yes, and in the version 7 version of icheck
(http://www.tuhs.org/Archive/PDP-11/Trees/V7/usr/src/cmd/dcheck.c) they
appear to have fixed it.
It is set to zero before both the pass1 and pass2 loops.

I'm pretty sure whoever added the feature to check more than one file system
at a time didn't test it very well in V6.   



From cowan at mercury.ccil.org  Sun Jun  1 03:16:17 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Sat, 31 May 2014 13:16:17 -0400
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <20140531161620.GL28034@mcvoy.com>
References: <20140531133051.5F2531DE37F@lignose.oclsc.org>
 <20140531160302.GB371@mercury.ccil.org>
 <20140531161620.GL28034@mcvoy.com>
Message-ID: <20140531171617.GB10214@mercury.ccil.org>

Larry McVoy scripsit:

> I love Rob Pike, he's spot on on a lot of stuff.  I'm a big fan of
> "if you think you need threads then your processes are too fat".

Oh, he's a brilliant fellow.  I don't know him personally, but I know
people who do, and I don't think I'd love him if I knew him.  Humanity has
always found it useful to keep its (demi)gods at arm's length at least.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Barry thirteen gules and argent on a canton azure fifty mullets of five
points of the second,  six, five, six, five, six, five, six, five, and six.
        --blazoning the U.S. flag


From tim.newsham at gmail.com  Sun Jun  1 04:58:39 2014
From: tim.newsham at gmail.com (Tim Newsham)
Date: Sat, 31 May 2014 08:58:39 -1000
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <20140531131504.AC41E18C0C8@mercury.lcs.mit.edu>
References: <20140531131504.AC41E18C0C8@mercury.lcs.mit.edu>
Message-ID: <CAGSRWbgL9cHNiva5MzS5Sz6k_=n4A7_EkzVU3GwNeOrPhqAbkA@mail.gmail.com>

There are bugs to be found, and it can be a fun hunt
(though not too much of a challenge).  Here are some
more (security related, as thats my inclination):

  http://marc.info/?l=bugtraq&m=108627540130457&w=2
  http://minnie.tuhs.org/pipermail/unix-jun72/2008-May/000126.html
  http://minnie.tuhs.org/pipermail/unix-jun72/2008-May/000250.html

Tim


On Sat, May 31, 2014 at 3:15 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> So it turns out the 'dcheck' distributed with V6 has two (well, three, but
> the third one was only a potential problem for me) bugs it.
>
>
> The first was a fence-post error on a table clearing operation; it could
> cause the entry for the last inode of the disk in the constructed table of
> directory entry counts to start with a non-zero count when a second disk was
> scanned. However, it was only triggered in very specific circumstances:
>
> - A larger disk was listed before a smaller one (either in the command line,
>     or compiled in)
> - The inode on the larger disk corresponding to the last inode on the smaller
>     one was in use
>
> I can understand how they never ran across this one.
>
>
> The other one, however, which was an un-initalized variable, should have
> bitten them anytime they had more than one disk listed! It caused the
> constructed table of directory entry counts to be partially or wholly
> (depending on the size of the two disks) blank in all disks after the first
> one, causing numerous (bogus) error reports.
>
> (It was also amusing to find an un-used procedure in the source; it looks
> like dcheck was written starting with the code for 'icheck' - which explains
> the second bug; since the logic in icheck is subtly different, that variable
> _is_ set properly in icheck.)
>
> How this bug never bit them I cannot understand - unless they saw it, and
> couldn't be bothered to find and fix it!
>
> To me, it's completely amazing to find such a serious bug in such a critical
> piece of widely-distributd code! A lesson for archaeologists...
>
>
> Anyway, a fixed version is here:
>
>   http://ana-3.lcs.mit.edu/~jnc/tech/unix/ucmd/dcheck.c
>
> if anyone cares/needs it.
>
>         Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs



-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com


From clemc at ccc.com  Sun Jun  1 05:48:09 2014
From: clemc at ccc.com (Clem Cole)
Date: Sat, 31 May 2014 15:48:09 -0400
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <20140531131504.AC41E18C0C8@mercury.lcs.mit.edu>
References: <20140531131504.AC41E18C0C8@mercury.lcs.mit.edu>
Message-ID: <86E5991D-308B-4700-946B-449A35C06084@ccc.com>

btw.  there is a v6 version of fsck floating around.  CMU was still running v6 when Ted did his OYOC.  he later moved it to unix/TS (aka v7) which was the release mechanics out side of BTL.   I'm wonder if I can find a readable copy. 


funny I remember the first time fsck saved our butts     we had had power failure and corrupted two file systems on the EE dept 11/34 I was running Icheck/dcheck and the like trying patch the system and getting it running a gaining.  this new grad student (tjk) says he has something he wanted to try that he wrote over the summer /he had started writing at michiga.     the machine was dead Ted had it on a tape and getting it on to an rk05 was a trick  - we ended up doing it on the IUS system in CS.  

once it was running we were in awe   man that program migrated to all the CMU pdp11s within hours

Clem
> On May 31, 2014, at 9:15 AM, jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:
> 
> So it turns out the 'dcheck' distributed with V6 has two (well, three, but
> the third one was only a potential problem for me) bugs it.
> 
> 
> The first was a fence-post error on a table clearing operation; it could
> cause the entry for the last inode of the disk in the constructed table of
> directory entry counts to start with a non-zero count when a second disk was
> scanned. However, it was only triggered in very specific circumstances:
> 
> - A larger disk was listed before a smaller one (either in the command line,
>    or compiled in)
> - The inode on the larger disk corresponding to the last inode on the smaller
>    one was in use
> 
> I can understand how they never ran across this one.
> 
> 
> The other one, however, which was an un-initalized variable, should have
> bitten them anytime they had more than one disk listed! It caused the
> constructed table of directory entry counts to be partially or wholly
> (depending on the size of the two disks) blank in all disks after the first
> one, causing numerous (bogus) error reports.
> 
> (It was also amusing to find an un-used procedure in the source; it looks
> like dcheck was written starting with the code for 'icheck' - which explains
> the second bug; since the logic in icheck is subtly different, that variable
> _is_ set properly in icheck.)
> 
> How this bug never bit them I cannot understand - unless they saw it, and
> couldn't be bothered to find and fix it!
> 
> To me, it's completely amazing to find such a serious bug in such a critical
> piece of widely-distributd code! A lesson for archaeologists...
> 
> 
> Anyway, a fixed version is here:
> 
>  http://ana-3.lcs.mit.edu/~jnc/tech/unix/ucmd/dcheck.c
> 
> if anyone cares/needs it.
> 
>    Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From doug at cs.dartmouth.edu  Sun Jun  1 09:24:57 2014
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 31 May 2014 19:24:57 -0400
Subject: [TUHS] Bugs in V6 'dcheck'
Message-ID: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu>

> Ken and Dennis and the other guys behind
> the earliest UNIX code were smart guys and good programmers,
> but they were far from perfect; and back in those days we
> were all a lot sloppier.

The observation that exploits may be able to parlay
mundane bugs into security holes was not a commonplace
back then--even in the Unix room. So input buffers were
often made "bigger than ever will be needed" and left
that way on the understanding that crashes are tolerable
on outlandish data. In an idle moment one day, Dennis fed
a huge line of input to most everything in /bin. To the
surprise of nobody, including Dennis, lots of programs
crashed. We WERE surprised a few years later, when a journal
published this fact as a research result. Does anybody 
remember who published that deep new insight and/or where?

Doug


From schoedel at kw.igs.net  Sun Jun  1 10:17:12 2014
From: schoedel at kw.igs.net (Kevin Schoedel)
Date: Sat, 31 May 2014 20:17:12 -0400
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu>
References: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu>
Message-ID: <p0621020acfb0211644cd@[192.168.0.16]>

At 7:24 ?pm -0400 2014/05/31, Doug McIlroy wrote:
>Does anybody
>remember who published that deep new insight and/or where?

Probably this:
B.P. Miller, L. Fredriksen, So, B. "An Empirical Study of the Reliability
of UNIX Utilities", Communications of the ACM 33, 12 (December 1990)


-- 
Kevin Schoedel <schoedel at kw.igs.net> VA3TCS


From scj at yaccman.com  Mon Jun  2 08:54:38 2014
From: scj at yaccman.com (scj at yaccman.com)
Date: Sun, 1 Jun 2014 15:54:38 -0700
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <p0621020acfb0211644cd@[192.168.0.16]>
References: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu>
 <p0621020acfb0211644cd@[192.168.0.16]>
Message-ID: <165d8f375f191dc4367028c096d457ce.squirrel@webmail.yaccman.com>

Doug is quite right that we were much more relaxed about security then. 
THe academic world was very much inspired at the time by the idea that one
could prove programs correct using mathematics.  I remember having some
very spirited arguments on this topic with some academics.  My argument
was roughly "Proving programs is stupid.  Look at Unix.  It's insanely
useful, but most programs can't be proved correct because they aren't!". 
Buffer overflow was one of the bugs I had in mind.  It was embarrassing in
later years to read about all the hackers exploiting these bugs.

In our defence, with only <= 64KB for programs and data and the slow
machines of the day, dynamic allocation and subscript checking were often
impractical...

Steve



> At 7:24 ?pm -0400 2014/05/31, Doug McIlroy wrote:
>>Does anybody
>>remember who published that deep new insight and/or where?
>
> Probably this:
> B.P. Miller, L. Fredriksen, So, B. "An Empirical Study of the Reliability
> of UNIX Utilities", Communications of the ACM 33, 12 (December 1990)
>
>
> --
> Kevin Schoedel <schoedel at kw.igs.net> VA3TCS
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>




From a.phillip.garcia at gmail.com  Mon Jun  2 09:48:48 2014
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Sun, 1 Jun 2014 18:48:48 -0500
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu>
References: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu>
Message-ID: <CAFCBnZuCmDpRsFtPVw14tOr-q=OAh7SxWQpShati8K=SfUDtPQ@mail.gmail.com>

On May 31, 2014 6:25 PM, "Doug McIlroy" <doug at cs.dartmouth.edu> wrote:
>
> > Ken and Dennis and the other guys behind
> > the earliest UNIX code were smart guys and good programmers,
> > but they were far from perfect; and back in those days we
> > were all a lot sloppier.
>
> The observation that exploits may be able to parlay
> mundane bugs into security holes was not a commonplace
> back then--even in the Unix room. So input buffers were
> often made "bigger than ever will be needed" and left
> that way on the understanding that crashes are tolerable
> on outlandish data. In an idle moment one day, Dennis fed
> a huge line of input to most everything in /bin. To the
> surprise of nobody, including Dennis, lots of programs
> crashed. We WERE surprised a few years later, when a journal
> published this fact as a research result. Does anybody
> remember who published that deep new insight and/or where?
>
> Doug

yeah, that's not really sporting. I've always wondered about something
else, though: Were the original Unix authors annoyed when they learned that
some irascible young upstart named Richard Stallman was determined to make
a free Unix clone? Was he a gadfly, or just some kook you decided to
ignore? The fathers of Unix have been strangely silent on this topic for
many years. Maybe nobody's ever asked?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140601/e6c13cc8/attachment.html>

From ron at ronnatalie.com  Mon Jun  2 11:11:30 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 1 Jun 2014 21:11:30 -0400
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <CAFCBnZuCmDpRsFtPVw14tOr-q=OAh7SxWQpShati8K=SfUDtPQ@mail.gmail.com>
References: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu>
 <CAFCBnZuCmDpRsFtPVw14tOr-q=OAh7SxWQpShati8K=SfUDtPQ@mail.gmail.com>
Message-ID: <A1F9F243-29E6-4831-AB34-BD7BDB312DFA@ronnatalie.com>

Some UPSTART named RMS in his whole odipherous spledor couldn't even spell LINUX.     If you read his earlier manifesto rants he hated UNIX with a passion.
Holding out the TOPS operating systems as the be-all and end-all of user interface.   Despite his disingenous propaganda, he didn't invent LINUX (or any other UNIX clone).
RMS didn't even enter onto the UNIX scene until after he had been burned by LMI/Symbolics/MIT over contributions he made to the Lisp Machine that he assumed would always be freely available.     I was a rather late comer to UNIX, having not started on it until 1977,   RMS wasn't anywhere around until over a decade later.

I was happy that Ken and Dennis and the folks were coming up with the design pattern and not worrying about every single bug in the system.   This was RESEARCH.     Those of us in the direct trenches at the places that got UNIX under the "scrap metal" provisions got to make our own contribution by increasing robustness and performance as well as extended the underlying paradigm.
> yeah, that's not really sporting. I've always wondered about something else, though: Were the original Unix authors annoyed when they learned that some irascible young upstart named Richard Stallman was determined to make a free Unix clone? Was he a gadfly, or just some kook you decided to ignore? The fathers of Unix have been strangely silent on this topic for many years. Maybe nobody's ever asked?
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140601/c8486838/attachment.html>

From doug at cs.dartmouth.edu  Mon Jun  2 12:09:26 2014
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 01 Jun 2014 22:09:26 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
Message-ID: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>

Phil Garcia wrote:
 I've always wondered about something
else, though: Were the original Unix authors annoyed when they learned that
some irascible young upstart named Richard Stallman was determined to make
a free Unix clone? Was he a gadfly, or just some kook you decided to
ignore? The fathers of Unix have been strangely silent on this topic for
many years. Maybe nobody's ever asked?

Gnu was always taken as a compliment. And of course the Unix clone
was pie in the sky until Linus came along. I wonder about the power
relationship underlying "GNU/Linux", as rms modestly styles it.

There are certain differences in taste between Unix and Gnu, vide
emacs and texinfo. (I grit my teeth every time a man page tells me,
"The full documentation for ___ is maintained as a Texinfo file.")
But all disagreement is swept away before the fact that the old 
familiar environment is everywhere, from Cray to Apple, with rms 
a very important contributor.

Doug


From a.phillip.garcia at gmail.com  Mon Jun  2 12:10:01 2014
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Sun, 1 Jun 2014 21:10:01 -0500
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <A1F9F243-29E6-4831-AB34-BD7BDB312DFA@ronnatalie.com>
References: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu>
 <CAFCBnZuCmDpRsFtPVw14tOr-q=OAh7SxWQpShati8K=SfUDtPQ@mail.gmail.com>
 <A1F9F243-29E6-4831-AB34-BD7BDB312DFA@ronnatalie.com>
Message-ID: <CAFCBnZs3GQ9NHw6AXUsH8OXCCzF0ENC_5hPijJMZiUKXaXYptw@mail.gmail.com>

On Jun 1, 2014 8:11 PM, "Ronald Natalie" <ron at ronnatalie.com> wrote:
>
> Some UPSTART named RMS in his whole odipherous spledor couldn't even
spell LINUX.

This I've always found ironic, that he's sore because people call the os
linux and don't give gnu credit, when gnu itself was simply a unix ripoff.

Trying to empathize with the creators of unix, I think I would've felt like
someone was stealing things I'd worked hard to produce. But I don't know.
Like you said, he wrote manifestos and rants, so I might just as well have
dismissed him as a nut. You could also take the magnanimous view that he
was actually helping spread your ideas, albeit while putting his own
political spin on things. I'm sorry, I wasn't trying to troll or start a
flame war. RMS is something of an enigma to me.

<snip>

> RMS didn't even enter onto the UNIX scene until after he had been burned
by LMI/Symbolics/MIT over contributions he made to the Lisp Machine that he
assumed would always be freely available.     I was a rather late comer to
UNIX, having not started on it until 1977,   RMS wasn't anywhere around
until over a decade later.

I think he likes to throw 1984 around as the year he wrote the 'gnu
manifesto'.

> I was happy that Ken and Dennis and the folks were coming up with the
design pattern and not worrying about every single bug in the system.
This was RESEARCH.     Those of us in the direct trenches at the places
that got UNIX under the "scrap metal" provisions got to make our own
contribution by increasing robustness and performance as well as extended
the underlying paradigm.

And it's a beautiful design that has adapted remarkably well to new
technologies for decades.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140601/cd1648ae/attachment.html>

From cowan at mercury.ccil.org  Mon Jun  2 12:24:20 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 1 Jun 2014 22:24:20 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
Message-ID: <20140602022420.GD18282@mercury.ccil.org>

Doug McIlroy scripsit:

> But all disagreement is swept away before the fact that the old 
> familiar environment is everywhere, from Cray to Apple, with rms 
> a very important contributor.

Amen.

My checkered career has taken me from Eunice to Microsoft Xenix System III
to Solaris to BSD386 to Linux (native and CoLinux) to Cygwin, and
except when playing a sysadmin I have never had to know or care which
flavor of the Grand Ole OSry I was using that year.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Assent may be registered by a signature, a handshake, or a click of a computer
mouse transmitted across the invisible ether of the Internet. Formality
is not a requisite; any sign, symbol or action, or even willful inaction,
as long as it is unequivocally referable to the promise, may create a contract.
       --Specht v. Netscape


From msokolov at ivan.Harhan.ORG  Mon Jun  2 12:14:25 2014
From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon)
Date: Mon, 2 Jun 2014 02:14:25 GMT
Subject: [TUHS] Bugs in V6 'dcheck'
Message-ID: <1406020214.AA11094@ivan.Harhan.ORG>

A. P. Garcia <a.phillip.garcia at gmail.com> wrote:

> Were the original Unix authors annoyed when they learned that
> some irascible young upstart named Richard Stallman was determined to make
> a free Unix clone?

A deeper, more profound question would be: how did these original Unix
authors feel about their employer owning the rights to their creation?
Did they feel any guilt at all for having had to sign over all rights
in exchange for their paychecks?

Did Dennis and/or Ken personally wish their creation were free to the
world, public domain, or were they personally in agreement with the
licensing policies of their employer?  I argue that this question is
far more important than how they felt about RMS (if they cared at all).

Ronald Natalie <ron at ronnatalie.com> wrote:

> [RMS] If you read his earlier manifesto rants he hated UNIX =
> with a passion.
> Holding out the TOPS operating systems as the be-all and end-all of user =
> interface.

I wish more people would point out this aspect of RMS and GNU.  While
I wholeheartedly agree with Richard on the general philosophy of free
software, i.e., the *ethics* part and the Four Freedoms, when it comes
to GNU as a specific OS, in technical terms, I've always disliked
everything about it.  I love UNIX, and as Ron pointed it out like few
people do, GNU was fundamentally born out of hatred for the thing I
love.

SF


From cowan at mercury.ccil.org  Mon Jun  2 12:51:23 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 1 Jun 2014 22:51:23 -0400
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <1406020214.AA11094@ivan.Harhan.ORG>
References: <1406020214.AA11094@ivan.Harhan.ORG>
Message-ID: <20140602025123.GE18282@mercury.ccil.org>

Michael Spacefalcon scripsit:

> Did Dennis and/or Ken personally wish their creation were free to the
> world, public domain, or were they personally in agreement with the
> licensing policies of their employer?  

The record is quite clear on that.  How the 50 fixes tape got out of Bell
Labs may not be as puzzling as the song the Sirens sang or who blew up
Mallow Bridge, but likewise the question is not beyond all conjecture.
Ken wanted those diffs out there, the more so because they didn't all
come from inside the Labs.

See the seventh page of
<http://cla.calpoly.edu/~lcall/354/kelty_two_bits_ch4.pdf> for details.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
'Tis the Linux rebellion / Let coders take their place,
The Linux-nationale / Shall Microsoft outpace,
We can write better programs / Our CPUs won't stall,
So raise the penguin banner of / The Linux-nationale.  --Greg Baker


From imp at bsdimp.com  Mon Jun  2 12:59:13 2014
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 1 Jun 2014 20:59:13 -0600
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
Message-ID: <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>


On Jun 1, 2014, at 8:09 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Phil Garcia wrote:
> I've always wondered about something
> else, though: Were the original Unix authors annoyed when they learned that
> some irascible young upstart named Richard Stallman was determined to make
> a free Unix clone? Was he a gadfly, or just some kook you decided to
> ignore? The fathers of Unix have been strangely silent on this topic for
> many years. Maybe nobody's ever asked?

In private moments, some of the BSD old-timers have told me they are silent
due to bad blood that Stallman’s early fund-raising and propaganda efforts
created. Why rehash 20 year old battles with an obvious nutcase, eh? Since
more than one person has told me this, so I think silence is a wide-spread
case of “If you can’t say anything nice, say nothing at all."

> Gnu was always taken as a compliment. And of course the Unix clone
> was pie in the sky until Linus came along. I wonder about the power
> relationship underlying "GNU/Linux", as rms modestly styles it.

Of course, it should be noted that the GNU project was totally incapable
of producing a working kernel… They did decent clones of user land stuff,
but Hurd was a total dead end...

> There are certain differences in taste between Unix and Gnu, vide
> emacs and texinfo. (I grit my teeth every time a man page tells me,
> "The full documentation for ___ is maintained as a Texinfo file.")
> But all disagreement is swept away before the fact that the old 
> familiar environment is everywhere, from Cray to Apple, with rms 
> a very important contributor.

Emacs is awesome….

Warner


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140601/f1059c8d/attachment.sig>

From jnc at mercury.lcs.mit.edu  Mon Jun  2 13:18:07 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  1 Jun 2014 23:18:07 -0400 (EDT)
Subject: [TUHS] Bugs in V6 'dcheck'
Message-ID: <20140602031807.8B4DC18C0AD@mercury.lcs.mit.edu>

    > From: "Ron Natalie" <ron at ronnatalie.com>

    > The variable in question was a global static, 'ino' (the current inode
    > number),

    > Static is a much overloaded word in C, it's just a global variable.

Sorry; I was using 'static' in the general CS sense, not C-specific!

    > in the version 7 version of icheck .. they appear to have fixed it.

Actually, they seem to have got all three bugs I saw (including the one I
hadn't actually experienced yet, which would cause a segmentation violation).


    > From: Tim Newsham <tim.newsham at gmail.com>

    > There are bugs to be found .. Here are some more (security related, as
    > thats my inclination):
    > ...
    > http://minnie.tuhs.org/pipermail/unix-jun72/2008-May/000126.html

Fascinating mailing list! Thanks for the pointer.

	Noel


From cowan at mercury.ccil.org  Mon Jun  2 13:18:13 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 1 Jun 2014 23:18:13 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
Message-ID: <20140602031813.GF18282@mercury.ccil.org>

Warner Losh scripsit:

> “If you can’t say anything nice, say nothing at all."

And a Good Thing Too.  Public squabbling about trivia serves no one's
interest except the enemies'.

> They did decent clones of user land stuff,

Much less buggy and more Posix-compliant, I think you mean.

(The .sig below was chosen at random and in advance, but it's fitting.)

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
We are lost, lost.  No name, no business, no Precious, nothing.  Only empty.
Only hungry: yes, we are hungry.  A few little fishes, nassty bony little
fishes, for a poor creature, and they say death.  So wise they are; so just,
so very just.  --Gollum


From grog at lemis.com  Mon Jun  2 13:17:15 2014
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Mon, 2 Jun 2014 13:17:15 +1000
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
Message-ID: <20140602031715.GA27136@eureka.lemis.com>

On Sunday,  1 June 2014 at 20:59:13 -0600, Warner Losh wrote:
>
> On Jun 1, 2014, at 8:09 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>
>> Phil Garcia wrote:
>> I've always wondered about something
>> else, though: Were the original Unix authors annoyed when they learned that
>> some irascible young upstart named Richard Stallman was determined to make
>> a free Unix clone? Was he a gadfly, or just some kook you decided to
>> ignore? The fathers of Unix have been strangely silent on this topic for
>> many years. Maybe nobody's ever asked?
>
> In private moments, some of the BSD old-timers have told me they are
> silent due to bad blood that Stallman?s early fund-raising and
> propaganda efforts created. Why rehash 20 year old battles with an
> obvious nutcase, eh? Since more than one person has told me this, so
> I think silence is a wide-spread case of ?If you can?t say anything
> nice, say nothing at all."

But now you've said something, and it's not nice.

Clearly this is indicative of the standpoints of the others as well.
A lot is simply personality conflict.  As you know, I don't share that
opinion, and I think the emphasis that FreeBSD places on ridding
itself of GNU software is unhealthy.  Yes, rms is "unusual", but that
goes for a lot of the BSD crowd too.  And I know enough people in the
Linux space who dislike him as well.

>> Gnu was always taken as a compliment. And of course the Unix clone
>> was pie in the sky until Linus came along. I wonder about the power
>> relationship underlying "GNU/Linux", as rms modestly styles it.
>
> Of course, it should be noted that the GNU project was totally
> incapable of producing a working kernel? They did decent clones of
> user land stuff, but Hurd was a total dead end...

But if you state that, you need to analyse why.  I think the big issue
was the grandiose goals that they set.  And who knows what might have
happened if Linux and the free BSDs hadn't come along?  I don't think
it's fair to simply dismiss it as a dead end.

>> There are certain differences in taste between Unix and Gnu, vide
>> emacs and texinfo...
>
> Emacs is awesome?.

Not part of my vocabulary, but I couldn't live without Emacs.  Shall
we degrade this discussion into a vi/Emacs fight?

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/59ec0160/attachment.sig>

From jnc at mercury.lcs.mit.edu  Mon Jun  2 13:34:05 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  1 Jun 2014 23:34:05 -0400 (EDT)
Subject: [TUHS] Bugs in V6 'dcheck'
Message-ID: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu>

    > From: norman at oclsc.org (Norman Wilson)

    > SP&E published a paper by Don Knuth discussing all the many bugs found
    > in TeX, including some statistical analysis. 

    > From: John Cowan <cowan at mercury.ccil.org>

    > "The Errors of TeX" was an excellent article. 

Thanks for the pointer; it sounds like a great paper, but alas the only
copies I could fine online were behind paywalls.


    > From: Clem Cole <clemc at ccc.com>

    > btw.  there is a v6 version of fsck floating around.	

Yes, we had it at MIT.

    > I'm wonder if I can find a readable copy.

As I've mentioned, I have this goal of putting the MIT Unix (the kernel was
basically PWB1, with a host of new applications) sources online.

I have recently discovered (in my basement!) two sets of full dump tapes
(1/2" magtape) of what I think are the whole filesystem, so if I can find a
way to get them read, we'll have the V6 fsck - and much more besides (such
as a TCP/IP for V6). So I think you may soon get your wish!

	Noel


From cowan at mercury.ccil.org  Mon Jun  2 13:37:46 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 1 Jun 2014 23:37:46 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602031715.GA27136@eureka.lemis.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
 <20140602031715.GA27136@eureka.lemis.com>
Message-ID: <20140602033746.GG18282@mercury.ccil.org>

Greg 'groggy' Lehey scripsit:

> Not part of my vocabulary, but I couldn't live without Emacs.  Shall
> we degrade this discussion into a vi/Emacs fight?

Sure, go ahead.  As a firm adherent to "ex", I'll umpire the contest.

-- 
"Well, I'm back."  --Sam        John Cowan <cowan at ccil.org>


From downing.nick at gmail.com  Mon Jun  2 14:04:43 2014
From: downing.nick at gmail.com (Nick Downing)
Date: Mon, 2 Jun 2014 14:04:43 +1000
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602031715.GA27136@eureka.lemis.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
 <20140602031715.GA27136@eureka.lemis.com>
Message-ID: <CAH1jEzYqVE0Vaj13Rgu-EH-NKoKeLP-PPy0x-1YLnqcW+Nt3bA@mail.gmail.com>

Yeah. I think Richard Stallman is a legend (umm if that's too close to
"awesome" vocabulary wise then let's say he's an inspiration :) :) ), I
totally agree with everything he's done for & on behalf of free software
and really it's easy to forget how totally locked out of the unix world I
was as a 10yr old MS Basic programming hobbyist or 20yr old MS Basic
programming developer, never even used an SCCS until I was nearly 30. My
professional life would have been way more productive and satisfying if
Stallman had come along much earlier... I knew people who used unix and
packet-switched networks such as X.25 but being run for profit by large
corporations it was totally out of my price range. I also remember how much
I just yearned to have the source code of MS DOS, CP/M, AppleSoft & DOS
3.3, etc, so many unanswered questions that were only partially alleviated
by books such as "Undocumented DOS" and "Beneath Apple DOS"... I did
eventually get some of those sources or a version of them when it was much
too late & was disappointed to see how mediocre they looked from
developer's viewpoint... community could have dome much better but were
locked out of the process & relegated to writing apps & device drivers that
took ages to get working in light of limited technical info.

I'll never be in that situation again thanks to Stallman's insights and
Torvalds's and everyone else's contribution. I deplore the infighting
though and have had bad experiences in trying to offer what little time I
could afford to open source projects, now I do not really bother & just use
the tools with my own private modifications. I do think Stallman has a
point about naming of Linux v. GNU/Linux though.

What I do not like about GNU is the "kitchen sink" philosophy of including
every little used feature in every utility with longer and longer command
line switches and manpages. Bash I guess is an extreme example of this, we
do not need a commandline shell that is 1Mb in size!! Another issue I have
is the incredibly complex tools such as GCC being written in plain C when
some subset of C++ would clearly be more appropriate given their
fundamentally object oriented design. This is very laborious, repetitive
and wasteful and involves a lot of differing "private solutions" to
already-solved problems. Further the build systems are totally broken, I
appreciate what automake/autoconf is doing but from a developer point of
view they are totally unwieldy and another example of the "kitchen sink"
philosophy of supporting every conceivable, and outdated, architecture.
Much better solutions exist for these kinds of problems.

For these reasons I would likely not work on a GNU project, however I use
the tools daily and simply ignore the parts I don't like. If software
development were left to me I would be infinitely subroutinized,
redesigning the CPU so I could redesign the ISA and then return to
redesigning the compiler followed by the OS kernel followed by the C
library, the windowing system and the apps hehehe so RMS perceived a need
and filled it within a useful timescale and I'm infinitely grateful :)

cheers, Nick
On 02/06/2014 1:26 PM, "Greg 'groggy' Lehey" <grog at lemis.com> wrote:

> On Sunday,  1 June 2014 at 20:59:13 -0600, Warner Losh wrote:
> >
> > On Jun 1, 2014, at 8:09 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> >
> >> Phil Garcia wrote:
> >> I've always wondered about something
> >> else, though: Were the original Unix authors annoyed when they learned
> that
> >> some irascible young upstart named Richard Stallman was determined to
> make
> >> a free Unix clone? Was he a gadfly, or just some kook you decided to
> >> ignore? The fathers of Unix have been strangely silent on this topic for
> >> many years. Maybe nobody's ever asked?
> >
> > In private moments, some of the BSD old-timers have told me they are
> > silent due to bad blood that Stallman?s early fund-raising and
> > propaganda efforts created. Why rehash 20 year old battles with an
> > obvious nutcase, eh? Since more than one person has told me this, so
> > I think silence is a wide-spread case of ?If you can?t say anything
> > nice, say nothing at all."
>
> But now you've said something, and it's not nice.
>
> Clearly this is indicative of the standpoints of the others as well.
> A lot is simply personality conflict.  As you know, I don't share that
> opinion, and I think the emphasis that FreeBSD places on ridding
> itself of GNU software is unhealthy.  Yes, rms is "unusual", but that
> goes for a lot of the BSD crowd too.  And I know enough people in the
> Linux space who dislike him as well.
>
> >> Gnu was always taken as a compliment. And of course the Unix clone
> >> was pie in the sky until Linus came along. I wonder about the power
> >> relationship underlying "GNU/Linux", as rms modestly styles it.
> >
> > Of course, it should be noted that the GNU project was totally
> > incapable of producing a working kernel? They did decent clones of
> > user land stuff, but Hurd was a total dead end...
>
> But if you state that, you need to analyse why.  I think the big issue
> was the grandiose goals that they set.  And who knows what might have
> happened if Linux and the free BSDs hadn't come along?  I don't think
> it's fair to simply dismiss it as a dead end.
>
> >> There are certain differences in taste between Unix and Gnu, vide
> >> emacs and texinfo...
> >
> > Emacs is awesome?.
>
> Not part of my vocabulary, but I couldn't live without Emacs.  Shall
> we degrade this discussion into a vi/Emacs fight?
>
> Greg
> --
> Sent from my desktop computer.
> Finger grog at FreeBSD.org for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft MUA reports
> problems, please read http://tinyurl.com/broken-mua
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/272d52ae/attachment.html>

From scj at yaccman.com  Mon Jun  2 14:08:20 2014
From: scj at yaccman.com (scj at yaccman.com)
Date: Sun, 1 Jun 2014 21:08:20 -0700
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602033746.GG18282@mercury.ccil.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
 <20140602031715.GA27136@eureka.lemis.com>
 <20140602033746.GG18282@mercury.ccil.org>
Message-ID: <8ddc2a2d9aeea13a5bc6f98903380f62.squirrel@webmail.yaccman.com>

Three comments on Gnu/Unix.

The first is that the Unix creators were very ambivalent about the AT&T
Lawyers.  The legal situation surrounding AT&T licensing software was
murky, and the lawyers attitude was often "let's wait 10 years and see
what happens in case law...".  I spent about six months trying to get the
PCC C grammar released to the public domain, with the notion that this
would help limit the splintering of the language that was starting to
happen pre ANSI C.  I couldn't get anywhere with that.

The second comment is that, for me personally, the ripping off bothered me
less than the complete lack of attribution of the original creators. 
There were easily two dozen people who contributed some significant code
and/or ideas to Unix, but you'd never know it by looking at Gnu.

The third comment is that the loss of central control has had its costs. 
I get a rash looking at the 500-page gcc manual, orders of magnitude
larger than the code for pcc.  It's hard to steer a sensible course
between stagnated central control and chaotic anarchy, but for my taste
letting every grad student with a couple of hours of spare time piddle on
the code base has not, on the whole, been a good thing.]

Steve



From cowan at mercury.ccil.org  Mon Jun  2 14:43:48 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 2 Jun 2014 00:43:48 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAH1jEzYqVE0Vaj13Rgu-EH-NKoKeLP-PPy0x-1YLnqcW+Nt3bA@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
 <20140602031715.GA27136@eureka.lemis.com>
 <CAH1jEzYqVE0Vaj13Rgu-EH-NKoKeLP-PPy0x-1YLnqcW+Nt3bA@mail.gmail.com>
Message-ID: <20140602044348.GJ18282@mercury.ccil.org>

Nick Downing scripsit:

> Bash I guess is an extreme example of this, we do not need a commandline
> shell that is 1Mb in size!!

Well, some people find it useful.  But if you want dash or Unix rc,
you know where to find them.

> Further the build systems are totally broken, I
> appreciate what automake/autoconf is doing but from a developer point of
> view they are totally unwieldy and another example of the "kitchen sink"
> philosophy of supporting every conceivable, and outdated, architecture.

Indeed.  I rather like the Chicken Scheme approach:  there is a Makefile
fragment for each supported architecture, currently BSD, Solaris, Android,
AIX, Haiku, iOS, MinGW with or without MSYS, Cygwin, Hurd, MacOSX,
and Linux.  If you want anything else, provide your own Makefile fragment.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Eric Raymond is the Margaret Mead of the Open Source movement.
          --Bruce Perens, a long time ago


From grog at lemis.com  Mon Jun  2 15:03:18 2014
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Mon, 2 Jun 2014 15:03:18 +1000
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602033746.GG18282@mercury.ccil.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
 <20140602031715.GA27136@eureka.lemis.com>
 <20140602033746.GG18282@mercury.ccil.org>
Message-ID: <20140602050317.GB27136@eureka.lemis.com>

On Sunday,  1 June 2014 at 23:37:46 -0400, John Cowan wrote:
> Greg 'groggy' Lehey scripsit:
>
>> Not part of my vocabulary, but I couldn't live without Emacs.  Shall
>> we degrade this discussion into a vi/Emacs fight?
>
> Sure, go ahead.  As a firm adherent to "ex", I'll umpire the
> contest.

:-)

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/58bb9036/attachment.sig>

From mah at mhorton.net  Mon Jun  2 14:05:43 2014
From: mah at mhorton.net (Mary Ann Horton)
Date: Sun, 01 Jun 2014 21:05:43 -0700
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu>
References: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu>
Message-ID: <538BF817.9070604@mhorton.net>

I would also love to find a way to read 9 track tapes back in. Everyone 
has ditched the hardware.   I have several 4BSD and System V tapes as 
well as personal tapes I'd love to read in.  (Anyone remember IBM 
"picture tapes"?)

On 06/01/2014 08:34 PM, Noel Chiappa wrote:
>      > From: norman at oclsc.org (Norman Wilson)
>
>      > SP&E published a paper by Don Knuth discussing all the many bugs found
>      > in TeX, including some statistical analysis.
>
>      > From: John Cowan <cowan at mercury.ccil.org>
>
>      > "The Errors of TeX" was an excellent article.
>
> Thanks for the pointer; it sounds like a great paper, but alas the only
> copies I could fine online were behind paywalls.
>
>
>      > From: Clem Cole <clemc at ccc.com>
>
>      > btw.  there is a v6 version of fsck floating around.	
>
> Yes, we had it at MIT.
>
>      > I'm wonder if I can find a readable copy.
>
> As I've mentioned, I have this goal of putting the MIT Unix (the kernel was
> basically PWB1, with a host of new applications) sources online.
>
> I have recently discovered (in my basement!) two sets of full dump tapes
> (1/2" magtape) of what I think are the whole filesystem, so if I can find a
> way to get them read, we'll have the V6 fsck - and much more besides (such
> as a TCP/IP for V6). So I think you may soon get your wish!
>
> 	Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs



From usotsuki at buric.co  Mon Jun  2 16:08:19 2014
From: usotsuki at buric.co (Steve Nickolas)
Date: Mon, 2 Jun 2014 06:08:19 +0000 (UTC)
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
Message-ID: <alpine.DEB.2.02.1406020606000.23388@localhost>

On Sun, 1 Jun 2014, Warner Losh wrote:

> Of course, it should be noted that the GNU project was totally incapable
> of producing a working kernel… They did decent clones of user land stuff,
> but Hurd was a total dead end...

The HURD isn't even a joke, it's just a punch line...

That said, to me with the userland, BSD gets it right, and GNU is a joke - 
slow and bloated.  You know how Microsoft is known for "embrace, extend 
and exterminate" ?  GNU does the same damn thing.

From arnold at skeeve.com  Mon Jun  2 16:23:38 2014
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 02 Jun 2014 00:23:38 -0600
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602044348.GJ18282@mercury.ccil.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
 <20140602031715.GA27136@eureka.lemis.com>
 <CAH1jEzYqVE0Vaj13Rgu-EH-NKoKeLP-PPy0x-1YLnqcW+Nt3bA@mail.gmail.com>
 <20140602044348.GJ18282@mercury.ccil.org>
Message-ID: <201406020623.s526Nctu017760@freefriends.org>

John Cowan <cowan at mercury.ccil.org> wrote:

> Indeed.  I rather like the Chicken Scheme approach:  there is a Makefile
> fragment for each supported architecture, currently BSD, Solaris, Android,
> AIX, Haiku, iOS, MinGW with or without MSYS, Cygwin, Hurd, MacOSX,
> and Linux.  If you want anything else, provide your own Makefile fragment.

This is only possible because of the standardization efforts at the
C and POSIX levels.  Remember that Autoconf/Automake were invented to
solve the issue of all the forks: SunOS / Solaris / HP-UX / Ultrix /
MIPS / Pryamid / DG-UX / ad nauseum.   Lots of things that were almost but
not quite entirely like V7 or System V Unix.

Today many of those players are no longer around, AND standardization of
header files and libraries means that C code is *more* portable than it
was in 1992.  So there's less need for those tools *now*, but that doesn't
mean they didn't solve a real problem when they first came along.

I'll agree on most of the GNU complaints (and I'm a GNU developer...);
the original Unix "Small Is Beautiful" baby has been thrown out along with
the proprietary licensing bath water. Sigh. (Boy, was that a great use
for an old cliche, or what? :-)

Thanks,

Arnold


From arnold at skeeve.com  Mon Jun  2 16:12:46 2014
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 02 Jun 2014 00:12:46 -0600
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu>
References: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu>
Message-ID: <201406020612.s526CkYO017517@freefriends.org>

>     > "The Errors of TeX" was an excellent article. 
>
> Thanks for the pointer; it sounds like a great paper, but alas the only
> copies I could fine online were behind paywalls.

IIRC it's reproduced in Knuth's book "Literate programming" which is
well worth ownding and reading. A soft copy might actually come with
TeX itself.

Arnold


From clemc at ccc.com  Mon Jun  2 22:04:37 2014
From: clemc at ccc.com (Clem Cole)
Date: Mon, 2 Jun 2014 08:04:37 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
Message-ID: <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>

On Sun, Jun 1, 2014 at 10:09 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Gnu was always taken as a compliment. And of course the Unix clone
> was pie in the sky until Linus came along.
>

​Actually I would say the real contribution was not emacs or the getting
the user space code rewritten, but gcc.  While compared to many commercial
compilers it ​has never been the "the best" but is seems like its always
"up there" when compared and in fact I find it a "better" compiler than
some of the commercial ones in the embedded space.

rms's gift was getting a "production quality" compiler in the everyone's
hands that was portable "enough" that it was basically OS independent.

As for UNIX clones, Doug, I would sort of differ with you on that.   There
were numerous "clones" and rewrites from Plauger's Irdis efforts to Andy's
Minux if you want to discount the slow rewrite from the inside out of BSD.

I content, what really made Linux happen was the ill fated AT&T vs BSDi/UCB
case -- a lot of people (myself included) miss understood and were worried
BSD would have to go away.   I would later be educated in realize, if AT&T
had won all of the UNIX "clones" would have had to go away in the west/Nato
countries.   And frankly, I'm not sure it would have survived that.

I agree with you about being annoyed with the words ""The full
documentation for ___ is maintained as a Texinfo file" but I find a number
of things in Linux that make me just as annoyed.    It seems like there are
a lot of changes because they could, not be cause it really mattered.

But then I remember that as you point out, it runs on everything and that
does make me smile and does make life so much easier for all of us.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/0893a4c0/attachment.html>

From ron at ronnatalie.com  Mon Jun  2 22:27:14 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 2 Jun 2014 08:27:14 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
Message-ID: <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>

Well PCC wasn't bad (we used it to build the compilers for the HEP Supercomputer), but you are correct GCC was reasonably good.
In addition to Idris mentioned, there was also Mark Williams's Coherent.   The bigger issues with these "clones" and the legitimate Unices like XENIX, IS/1, etc... were that the PC platform wasn't quite there yet.     Still with all it's flaws, on the 286 and later UNIX actually did run in protected mode, something it took ages for DOS/Windows (one can argue backwards compatibility with the early processors) or Apple (no excuse here, the early Macs were 68000's which had protection) to pick up upon.

Wasn't just us in academia who were concerned.   Spent an evening sitting in the hallway of some dormitory (UDel?) with Dennis Mumaugh from the NSA discussing security holes we'd fixed.

Carping about obscure bugs in Version 6 is sort of silly (as I stated, they were even fixed as of V7) and frankly, software security / reliability was a different world back then.    We had less of a time with our TOPS-10 system only because we didn't give students so much free rain on the accounts (compared to the UNIX system which you just had to ask pretty much) but I still remember crashing the EXEC-8 system at UofM with a corrupted file I kept around.

Of course there were always hardware bugs to deal with.   There were some on the PDP-11 and even on the 386 (when I was working with AIX ...really the UCLA Locus version of UNIX) there was disgusting hacks that doiubled up the paging protection with the old segment-offset stuff because of a security bug there.



From ron at ronnatalie.com  Mon Jun  2 22:31:34 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 2 Jun 2014 08:31:34 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602050317.GB27136@eureka.lemis.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
 <20140602031715.GA27136@eureka.lemis.com>
 <20140602033746.GG18282@mercury.ccil.org>
 <20140602050317.GB27136@eureka.lemis.com>
Message-ID: <D877F795-3659-4EDC-972F-22BE6C4A36AB@ronnatalie.com>

Amusingly I never learned VI.    I had worked for a group that was beholden to Interactive Systems editor (which I believe was a variant of Yost's Rand Editor) and by the time I left there I was working with various pre-GNU Unix EMACS (Warren Montgomery, JOVE, Gosling).    I even worked for Unipress for a very short period as a consultant.

To this day if there's no EMACS I juse use ed or ex.     It always amazed my coworkers how fast I fly in line editor mode.

On Jun 2, 2014, at 1:03 AM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
>> 
>> 
>>> Not part of my vocabulary, but I couldn't live without Emacs.  Shall
>>> we degrade this discussion into a vi/Emacs fight?
>> 
>> Sure, go ahead.  As a firm adherent to "ex", I'll umpire the
>> contest.
> 
> :


From clemc at ccc.com  Mon Jun  2 23:28:58 2014
From: clemc at ccc.com (Clem Cole)
Date: Mon, 2 Jun 2014 09:28:58 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
Message-ID: <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>

On Mon, Jun 2, 2014 at 8:27 AM, Ronald Natalie <ron at ronnatalie.com> wrote:

> Well PCC wasn't bad (we used it to build the compilers for the HEP
> Supercomputer), but you are correct GCC was reasonably good.


​Ron you are right..   A number of us used dmr's compiler much less Steve's
compiler to "port UNIX" to a lot of different things (some where good and
some not so good - my own attempt at retargeting the V7 Rtichie compiler to
yet to be name processed experimental process from Moto (later called the
68000) proved "good enough" for the Magnolia project at Tek but it was not
really not a very good compiler).  But you had to have an AT&T license to
get it.   Admittedly a lot of universities did and that did certainly cause
C to get a huge foot hold over its contemporaries (say BCPL, BLISS and
maybe PL/360).

IMHO: what rms did was put a production quality compiler into play that had
sources, that anyone could use and anyone could hack on without having to
purchase it or need some sort of license other than his GPL.  At the time,
there had been lots of attempts at different compilers both "free" and
commercial - some with sources some not (I fondly remember Ron Cain's Small
C for the 8080 being pushed in Byte Magazine the late 1970s/early 1980)​.
Even Whitesmith's (Plauger's) compiler  was really not what would we have
called production code quality.

gcc was not (still is not) perfect and compared to a number of commercial
compilers -- say something like the current Intel compiler or the old DEC,
Masscomp or Sun compilers.   But the "gcc family" did prove to be fairly
easy move to a lot of UNIX/UNIX-like and non-UNIX OS platforms, at the same
time able to be retarget to a number of different ISAs, even a number of
different front ends; all while generally creating good/reasonable if not
darned good/close to optimal code (at least for many of the targets were
the most popular/that mattered).

Frankly, we have seen few developer suites that have been as lasting and I
might suggest that until the LLVM project there has been few (none) that
have had a chance of being so [Tannebaum's compiler kit maybe - but I never
same that it never really went anywhere].

My observation is that without a "pretty good" compiler that was reasonably
"universal" the rest of the command suite would have languished/not
happened.   As Doug points out the base OS really never happened from rms
(they had Trix, then the Hurd and finally defaulted to Linux).   But the
command suite was able to grow and lots of people besides rms contribute to
it, because the basic development tools were there.   As strange and
difficult a person he is, I suspect we do all own rms a certain level of
thanks for the basic dev tools.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/5178fdff/attachment.html>

From tfb at tfeb.org  Tue Jun  3 00:11:45 2014
From: tfb at tfeb.org (Tim Bradshaw)
Date: Mon, 2 Jun 2014 15:11:45 +0100
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
Message-ID: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>


On 2 Jun 2014, at 14:28, Clem Cole <clemc at ccc.com> wrote:
> [About gcc]
> But the command suite was able to grow and lots of people besides rms contribute to it, because the basic development tools were there.   As strange and difficult a person he is, I suspect we do all own rms a certain level of thanks for the basic dev tools.

In particular I think the existence of GCC was critical to the existence of Linux: there is some complicated history involving a GCC port to ?Minix?, which I think was done because Minix's compiler was rudimentary, and that port enabling some Finnish guy (using Minix I guess) to bring up a kernel.  I suspect there are people on this list who remember this better than I do though.

--tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/b0fa22fe/attachment.html>

From cowan at mercury.ccil.org  Tue Jun  3 00:24:48 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 2 Jun 2014 10:24:48 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
Message-ID: <20140602142446.GM18282@mercury.ccil.org>

Ronald Natalie scripsit:

> Still with all it's flaws, on the 286 and later UNIX actually did run in
> protected mode, something it took ages for DOS/Windows (one can argue
> backwards compatibility with the early processors) or Apple (no excuse
> here, the early Macs were 68000's which had protection) to pick up upon.

The original Mac 128K was a 68000 processor, and IIRC memory protection
didn't arrive until the 68020.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
'Tis the Linux rebellion / Let coders take their place,
The Linux-nationale / Shall Microsoft outpace,
We can write better programs / Our CPUs won't stall,
So raise the penguin banner of / The Linux-nationale.  --Greg Baker


From clemc at ccc.com  Tue Jun  3 00:25:58 2014
From: clemc at ccc.com (Clem Cole)
Date: Mon, 2 Jun 2014 10:25:58 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
Message-ID: <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>

Tim - cart and horse reversed.. ;-)

Linus did not like the fact the when Andy wrote Minux, he and his students
did not use the 386 MMU HW.   It was made to run on a 8086/8088 -- straight
PC/XT  because Andy wanted the lowest cost of entry for his students.
Also at the time, Andy's compiler tool kit was not as easy to get the
source.

My memory on this part is hazy, but I think you had to purchase the
compiler sources.   So  Linus started with MINUX and started to add more
and more support.   He eventually tossed out the ukernel nature of Minux
and went the more traditional kernel architecture.    He and Andy would
famously fight about that choice on usenet.

Linus this would eventually need a compiler and pulled rms' suite.


The funny part is that his University has 386BSD (aka 4.2 for the 386) at
the time which did use the MMU, had networking and even the first step at
X11.  At the time I had helped the guys get the AT disk driver working as I
had access to all the Western Digital documentation.   But to get the code
from CRSG, you needed at BSD license, which required an AT&T license.
Linus' university had one, but he did know know the magic ftp site to
download or have access.

I've often wondered what would have happened if he had known about it.

And again, fast forward about 18-24 months and folks like me were worried
when the BSDi case came out that we were going to lose access to a UNIX for
the Intel processor.   So we started to help him, even though at the time
is a huge step backwards.

Clearly, the "powers" at AT&T really did not know they were awaking a
sleeping animal in the hacker community.

Clem


On Mon, Jun 2, 2014 at 10:11 AM, Tim Bradshaw <tfb at tfeb.org> wrote:

>
> On 2 Jun 2014, at 14:28, Clem Cole <clemc at ccc.com> wrote:
>
> [About gcc]
>
> But the command suite was able to grow and lots of people besides rms
> contribute to it, because the basic development tools were there.   As
> strange and difficult a person he is, I suspect we do all own rms a certain
> level of thanks for the basic dev tools.
>
>
> In particular I think the existence of GCC was critical to the existence
> of Linux: there is some complicated history involving a GCC port to
> ?Minix?, which I think was done because Minix's compiler was rudimentary,
> and that port enabling some Finnish guy (using Minix I guess) to bring up a
> kernel.  I suspect there are people on this list who remember this better
> than I do though.
>
> --tim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/1d034672/attachment.html>

From arnold at skeeve.com  Tue Jun  3 00:26:57 2014
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 02 Jun 2014 08:26:57 -0600
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
Message-ID: <201406021426.s52EQvxp007291@freefriends.org>

Tim Bradshaw <tfb at tfeb.org> wrote:
>
> In particular I think the existence of GCC was critical to the existence
> of Linux:

Linus himself has said as much.

I can't find the quote, but I'm pretty sure he acknowledges that.

Arnold


From ron at ronnatalie.com  Tue Jun  3 00:29:30 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 2 Jun 2014 10:29:30 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602142446.GM18282@mercury.ccil.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <20140602142446.GM18282@mercury.ccil.org>
Message-ID: <7DC97BD4-337C-4E32-9EA3-AA485923AC97@ronnatalie.com>


On Jun 2, 2014, at 10:24 AM, John Cowan <cowan at mercury.ccil.org> wrote:

> Ronald Natalie scripsit:
> 
>> Still with all it's flaws, on the 286 and later UNIX actually did run in
>> protected mode, something it took ages for DOS/Windows (one can argue
>> backwards compatibility with the early processors) or Apple (no excuse
>> here, the early Macs were 68000's which had protection) to pick up upon.
> 
> The original Mac 128K was a 68000 processor, and IIRC memory protection
> didn't arrive until the 68020.
> 
> -- 

Yeah, you're right.   You could get it off-chip with the -010 or it was integrated with the -020.



From cowan at mercury.ccil.org  Tue Jun  3 00:30:20 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 2 Jun 2014 10:30:20 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
Message-ID: <20140602143020.GN18282@mercury.ccil.org>

Clem Cole scripsit:

> Frankly, we have seen few developer suites that have been as lasting and I
> might suggest that until the LLVM project there has been few (none) that
> have had a chance of being so [Tannebaum's compiler kit maybe - but I never
> same that it never really went anywhere].

"The university is free but the compiler is not", as Tanenbaum said to RMS.
However, eventually he caught up, and it was BSD-licensed in 2003.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Heckler: "Go on, Al, tell 'em all you know.  It won't take long."
Al Smith: "I'll tell 'em all we *both* know.  It won't take any longer."


From clemc at ccc.com  Tue Jun  3 00:37:52 2014
From: clemc at ccc.com (Clem Cole)
Date: Mon, 2 Jun 2014 10:37:52 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602142446.GM18282@mercury.ccil.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <20140602142446.GM18282@mercury.ccil.org>
Message-ID: <CAC20D2OLiArKCA9ARAAdGEcBM4wyiCYqewnZ9vGoFYN2_zZAkA@mail.gmail.com>

On Mon, Jun 2, 2014 at 10:24 AM, John Cowan <cowan at mercury.ccil.org> wrote:

> The original Mac 128K was a 68000 processor, and IIRC memory protection
> didn't arrive until the 68020.
>



​Sort of.  Did not arrive to >>Apple<< until the '020 based Mac-II.

Les Crudele (one the 68k's designers) tells a great story about this.   The
original device had a PDP-11 base/limit register MMU as an external chip
who's number I forget (and could not do demand paging by itself -- Masscomp
and Apollo would use 2 of them and build their own MMU).    According to
Les, Moto offered to give Apple the MMU chip at a substantial discount
(maybe even free) if they would use it for the Mac.  But Jobs famously said
it was a personal computer and did not need it (remember the Alto's did not
have an MMU either).

Later, Moto would release the '010  ​which could do demanding paging with
help of an external MMU.  The Stanford University Network Terminal (aka
"SUN" board) could use the '10.   I don't think Apple did themselves, but
my memory is that the was an after market '010 mod for some of the Macs.

At Masscomp, we retrofited the original CPU board to take a '010.   In this
mode, the 'fixer' 68K and the '010 could run in parallel during a page
fault, which was slightly faster.   But functionally, to the end user it
was the same as two 68K's.  I'm not sure if Apollo did a retrofit.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/4c960b2c/attachment.html>

From cowan at mercury.ccil.org  Tue Jun  3 00:41:05 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 2 Jun 2014 10:41:05 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
Message-ID: <20140602144105.GO18282@mercury.ccil.org>

Clem Cole scripsit:

> I've often wondered what would have happened if he had known about it.

Linus is on record as saying that if either the Hurd or the 386BSD system
had been available to him, he would never have written the Linux kernel.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
If I have seen farther than others, it is because I was standing on
the shoulders of giants.  --Isaac Newton


From aps at ieee.org  Tue Jun  3 00:50:08 2014
From: aps at ieee.org (Armando Stettner)
Date: Mon, 2 Jun 2014 07:50:08 -0700
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602144105.GO18282@mercury.ccil.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
Message-ID: <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>

And, to think, I thought operating system wars and editor religions had died long ago....

  aps.


Begin forwarded message:

> From: John Cowan <cowan at mercury.ccil.org>
> Subject: Re: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
> Date: June 2, 2014 at 7:41:05 AM PDT
> To: Clem Cole <clemc at ccc.com>
> Cc: TUHS main list <tuhs at minnie.tuhs.org>, Tim Bradshaw <tfb at tfeb.org>, Doug McIlroy <doug at cs.dartmouth.edu>
> 
> Clem Cole scripsit:
> 
>> I've often wondered what would have happened if he had known about it.
> 
> Linus is on record as saying that if either the Hurd or the 386BSD system
> had been available to him, he would never have written the Linux kernel.
> 
> -- 
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> If I have seen farther than others, it is because I was standing on
> the shoulders of giants.  --Isaac Newton
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 


From cowan at mercury.ccil.org  Tue Jun  3 03:35:21 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 2 Jun 2014 13:35:21 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <201406020623.s526Nctu017760@freefriends.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
 <20140602031715.GA27136@eureka.lemis.com>
 <CAH1jEzYqVE0Vaj13Rgu-EH-NKoKeLP-PPy0x-1YLnqcW+Nt3bA@mail.gmail.com>
 <20140602044348.GJ18282@mercury.ccil.org>
 <201406020623.s526Nctu017760@freefriends.org>
Message-ID: <20140602173521.GX18282@mercury.ccil.org>

arnold at skeeve.com scripsit:


> This is only possible because of the standardization efforts at the
> C and POSIX levels.  Remember that Autoconf/Automake were invented to
> solve the issue of all the forks: SunOS / Solaris / HP-UX / Ultrix /
> MIPS / Pryamid / DG-UX / ad nauseum.   Lots of things that were almost but
> not quite entirely like V7 or System V Unix.

Oh, absolutely.  But Autotools themselves are very unstable, so we've
apparently replaced spatial variation with longitudinal variation.
The Chicken project was undergoing too much churn trying to run correctly
with different installed versions of Autotools.  So we switched to CMake,
but that was even more unstable, and couldn't handle a bootstrapped
self-compiler well.

So finally we switched to the current scheme of Makefile fragments.
Each fragment specifies appropriate cc and ld options, including libraries
required, and then writes out a chicken-defaults.h file with a bunch of
HAVE_* macros.  That's all that's needed.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
That you can cover for the plentiful and often gaping errors, misconstruals
and disinformation in your posts through sheer volume -- that is another
misconception.  --Mike to Peter


From tim.newsham at gmail.com  Tue Jun  3 04:41:36 2014
From: tim.newsham at gmail.com (Tim Newsham)
Date: Mon, 2 Jun 2014 08:41:36 -1000
Subject: [TUHS] unix history git
Message-ID: <CAGSRWbhKJEHaxkV51R4TBYRvZRO5WycLn__PsV4pe+B9kQSKww@mail.gmail.com>

have you guys seen this?
https://github.com/dspinellis/unix-history-repo

(I'm not involved, just came across it by way of twitter)

-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com


From brantley at coraid.com  Tue Jun  3 04:27:02 2014
From: brantley at coraid.com (Brantley Coile)
Date: Mon, 2 Jun 2014 18:27:02 +0000
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>,
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
Message-ID: <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>

Isn't it part of the nostalgia?  

iPhone email

> On Jun 2, 2014, at 10:57 AM, "Armando Stettner" <aps at ieee.org> wrote:
> 
> And, to think, I thought operating system wars and editor religions had died long ago....
> 
>  aps.
> 
> 
> Begin forwarded message:
> 
>> From: John Cowan <cowan at mercury.ccil.org>
>> Subject: Re: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
>> Date: June 2, 2014 at 7:41:05 AM PDT
>> To: Clem Cole <clemc at ccc.com>
>> Cc: TUHS main list <tuhs at minnie.tuhs.org>, Tim Bradshaw <tfb at tfeb.org>, Doug McIlroy <doug at cs.dartmouth.edu>
>> 
>> Clem Cole scripsit:
>> 
>>> I've often wondered what would have happened if he had known about it.
>> 
>> Linus is on record as saying that if either the Hurd or the 386BSD system
>> had been available to him, he would never have written the Linux kernel.
>> 
>> -- 
>> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
>> If I have seen farther than others, it is because I was standing on
>> the shoulders of giants.  --Isaac Newton
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From imp at bsdimp.com  Tue Jun  3 04:44:46 2014
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 2 Jun 2014 12:44:46 -0600
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602173521.GX18282@mercury.ccil.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
 <20140602031715.GA27136@eureka.lemis.com>
 <CAH1jEzYqVE0Vaj13Rgu-EH-NKoKeLP-PPy0x-1YLnqcW+Nt3bA@mail.gmail.com>
 <20140602044348.GJ18282@mercury.ccil.org>
 <201406020623.s526Nctu017760@freefriends.org>
 <20140602173521.GX18282@mercury.ccil.org>
Message-ID: <0336AA23-2BB0-4ACE-80DC-570B2A32F19E@bsdimp.com>


On Jun 2, 2014, at 11:35 AM, John Cowan <cowan at mercury.ccil.org> wrote:

> arnold at skeeve.com scripsit:
> 
> 
>> This is only possible because of the standardization efforts at the
>> C and POSIX levels.  Remember that Autoconf/Automake were invented to
>> solve the issue of all the forks: SunOS / Solaris / HP-UX / Ultrix /
>> MIPS / Pryamid / DG-UX / ad nauseum.   Lots of things that were almost but
>> not quite entirely like V7 or System V Unix.
> 
> Oh, absolutely.  But Autotools themselves are very unstable, so we've
> apparently replaced spatial variation with longitudinal variation.
> The Chicken project was undergoing too much churn trying to run correctly
> with different installed versions of Autotools.  So we switched to CMake,
> but that was even more unstable, and couldn't handle a bootstrapped
> self-compiler well.
> 
> So finally we switched to the current scheme of Makefile fragments.
> Each fragment specifies appropriate cc and ld options, including libraries
> required, and then writes out a chicken-defaults.h file with a bunch of
> HAVE_* macros.  That's all that's needed.

Sounds a bit like imake-uberlite…  Or should I not mention imake lest the love-fest for all things evil continue on it. :)

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/08a4544b/attachment.sig>

From cowan at mercury.ccil.org  Tue Jun  3 04:52:00 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 2 Jun 2014 14:52:00 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <0336AA23-2BB0-4ACE-80DC-570B2A32F19E@bsdimp.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <00668C2D-BF21-44EA-A7D8-A9530CA24551@bsdimp.com>
 <20140602031715.GA27136@eureka.lemis.com>
 <CAH1jEzYqVE0Vaj13Rgu-EH-NKoKeLP-PPy0x-1YLnqcW+Nt3bA@mail.gmail.com>
 <20140602044348.GJ18282@mercury.ccil.org>
 <201406020623.s526Nctu017760@freefriends.org>
 <20140602173521.GX18282@mercury.ccil.org>
 <0336AA23-2BB0-4ACE-80DC-570B2A32F19E@bsdimp.com>
Message-ID: <20140602185200.GZ18282@mercury.ccil.org>

Warner Losh scripsit:

> Sounds a bit like imake-uberlite…  Or should I not mention imake
> lest the love-fest for all things evil continue on it. :)

Not much like, because there is no configuration tool at all.
You just say "make PLATFORM=foo" and it includes Makefile.foo.
I've attached a couple of Makefile fragments to this email for
easy comparison.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Principles.  You can't say A is made of B or vice versa.
All mass is interaction.  --Richard Feynman
-------------- next part --------------
# Makefile.linux - configuration for Linux -*- Makefile -*-
#
# Copyright (c) 2008-2014, The Chicken Team
# Copyright (c) 2007, Felix L. Winkelmann
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following
# conditions are met:
#
#   Redistributions of source code must retain the above copyright notice, this list of conditions and the following
#     disclaimer. 
#   Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
#     disclaimer in the documentation and/or other materials provided with the distribution. 
#   Neither the name of the author nor the names of its contributors may be used to endorse or promote
#     products derived from this software without specific prior written permission. 
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS
# OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
# AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.


ifneq ($(CONFIG),)
include $(CONFIG)
endif

SRCDIR ?= ./

# platform configuration

ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh)

# options

C_COMPILER_OPTIONS ?= -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H
ifdef DEBUGBUILD
C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused
else
ifdef OPTIMIZE_FOR_SPEED
C_COMPILER_OPTIMIZATION_OPTIONS ?= -O3 -fomit-frame-pointer
else
C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer
endif
endif
LINKER_LINK_SHARED_LIBRARY_OPTIONS = -shared
LINKER_LINK_SHARED_DLOADABLE_OPTIONS = -L. -shared -Wl,-R"$(RUNTIME_LINKER_PATH)"
LINKER_LINK_SHARED_PROGRAM_OPTIONS = -Wl,-R"$(RUNTIME_LINKER_PATH)"
LIBCHICKEN_SO_LINKER_OPTIONS = -Wl,-soname,lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX).so.$(BINARYVERSION)
LIBRARIES = -lm -ldl
NEEDS_RELINKING = yes
USES_SONAME = yes

# special files

CHICKEN_CONFIG_H = chicken-config.h

# select default and internal settings

include $(SRCDIR)/defaults.make

chicken-config.h: chicken-defaults.h
	echo "/* GENERATED */" >$@
	echo "#define HAVE_DIRENT_H 1" >>$@
	echo "#define HAVE_DLFCN_H 1" >>$@
	echo "#define HAVE_INTTYPES_H 1" >>$@
	echo "#define HAVE_LIMITS_H 1" >>$@
	echo "#define HAVE_LONG_LONG 1" >>$@
	echo "#define HAVE_MEMMOVE 1" >>$@
	echo "#define HAVE_MEMORY_H 1" >>$@
	echo "#define HAVE_POSIX_POLL 1" >>$@
	echo "#define HAVE_SIGACTION 1" >>$@
	echo "#define HAVE_SIGSETJMP 1" >>$@
	echo "#define HAVE_SIGPROCMASK 1" >>$@
	echo "#define HAVE_STDINT_H 1" >>$@
	echo "#define HAVE_STDLIB_H 1" >>$@
	echo "#define HAVE_STRERROR 1" >>$@
	echo "#define HAVE_STRINGS_H 1" >>$@
	echo "#define HAVE_STRING_H 1" >>$@
	echo "#define HAVE_STRTOLL 1" >>$@
	echo "#define HAVE_STRTOQ 1" >>$@
	echo "#define HAVE_SYS_STAT_H 1" >>$@
	echo "#define HAVE_SYS_TYPES_H 1" >>$@
	echo "#define HAVE_SETENV 1" >>$@
	echo "#define HAVE_UNISTD_H 1" >>$@
	echo "#define HAVE_UNSIGNED_LONG_LONG 1" >>$@
	echo "#define STDC_HEADERS 1" >>$@
	echo "#define HAVE_ALLOCA 1" >>$@
	echo "#define HAVE_ALLOCA_H 1" >>$@
	echo "#define HAVE_GRP_H 1" >>$@
	echo "#define HAVE_ERRNO_H 1" >>$@
	echo "#define HAVE_SYSEXITS_H 1" >>$@
	echo "#define HAVE_MEMMOVE 1" >>$@
	echo "#define C_STACK_GROWS_DOWNWARD 1" >>$@
ifdef GCHOOKS
	echo "#define C_GC_HOOKS" >>$@
endif
ifdef SYMBOLGC
	echo "#define C_COLLECT_ALL_SYMBOLS" >>$@
endif
ifneq ($(HACKED_APPLY),)
	echo "#define C_HACKED_APPLY" >>$@
endif
	cat chicken-defaults.h >>$@

include $(SRCDIR)/rules.make
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.bsd
Type: chemical/x-crossfire
Size: 4200 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/6b0fc4e0/attachment.bsd>
-------------- next part --------------
# Makefile.solaris - configuration for Solaris -*- Makefile -*-
#
# Copyright (c) 2008-2014, The Chicken Team
# Copyright (c) 2007, Felix L. Winkelmann
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following
# conditions are met:
#
#   Redistributions of source code must retain the above copyright notice, this list of conditions and the following
#     disclaimer. 
#   Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
#     disclaimer in the documentation and/or other materials provided with the distribution. 
#   Neither the name of the author nor the names of its contributors may be used to endorse or promote
#     products derived from this software without specific prior written permission. 
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS
# OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
# AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.


ifneq ($(CONFIG),)
include $(CONFIG)
endif

SRCDIR = ./

# platform configuration

ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh)
# default to gcc - use "make ... C_COMPILER=cc ..." to use SunPro CC
export C_COMPILER ?= gcc
export INSTALL_PROGRAM ?= ginstall

# options

ifeq ($(C_COMPILER),cc)
ifneq (,$(filter-out x86 x86-64,$(ARCH))) # -xannotate=no is not supported on x86/x86-64
DISABLE_ANNOTATIONS=-xannotate=no
else
DISABLE_ANNOTATIONS=
endif
C_COMPILER_OPTIONS ?= -errtags -xdebugformat=stabs $(DISABLE_ANNOTATIONS) -DHAVE_CHICKEN_CONFIG_H
else
C_COMPILER_OPTIONS ?= -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H
endif

ifdef DEBUGBUILD
ifeq ($(C_COMPILER),cc)
C_COMPILER_OPTIMIZATION_OPTIONS ?= -g +w
else
C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused
endif
else
ifdef OPTIMIZE_FOR_SPEED
ifeq ($(C_COMPILER),cc)
C_COMPILER_OPTIMIZATION_OPTIONS += -g -xO4
else
C_COMPILER_OPTIMIZATION_OPTIONS ?= -O3 -fomit-frame-pointer
endif
else
ifeq ($(C_COMPILER),cc)
C_COMPILER_OPTIMIZATION_OPTIONS += -g -xO3
else
C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer
endif
endif
endif

ifeq ($(C_COMPILER),cc) # Assuming 'cc' means SunW/SunStudio compiler
LINKER_LINK_SHARED_LIBRARY_OPTIONS = -G $(DISABLE_ANNOTATIONS)
LINKER_LINK_SHARED_DLOADABLE_OPTIONS = -G $(DISABLE_ANNOTATIONS) -R"$(RUNTIME_LINKER_PATH)" -L.
LINKER_LINK_SHARED_PROGRAM_OPTIONS = -R"$(RUNTIME_LINKER_PATH)"
else
LINKER_LINK_SHARED_LIBRARY_OPTIONS = -shared
LINKER_LINK_SHARED_DLOADABLE_OPTIONS = -shared -Wl,-R"$(RUNTIME_LINKER_PATH)" -Wl,-L.
LINKER_LINK_SHARED_PROGRAM_OPTIONS = -Wl,-R"$(RUNTIME_LINKER_PATH)"
endif
LIBRARIES = -lsocket -lnsl -lm -ldl -lrt
NEEDS_RELINKING = yes
USES_SONAME = yes

# special files

CHICKEN_CONFIG_H = chicken-config.h

# select default and internal settings

include $(SRCDIR)/defaults.make

chicken-config.h: chicken-defaults.h
	echo "/* END OF FILE */" >$@
	echo "#define HAVE_DIRENT_H 1" >>$@
	echo "#define HAVE_DLFCN_H 1" >>$@
	echo "#define HAVE_INTTYPES_H 1" >>$@
	echo "#define HAVE_LIMITS_H 1" >>$@
	echo "#define HAVE_LONG_LONG 1" >>$@
	echo "#define HAVE_MEMMOVE 1" >>$@
	echo "#define HAVE_MEMORY_H 1" >>$@
	echo "#define HAVE_POSIX_POLL 1" >>$@
	echo "#define HAVE_SIGACTION 1" >>$@
	echo "#define HAVE_STDINT_H 1" >>$@
	echo "#define HAVE_STDLIB_H 1" >>$@
	echo "#define HAVE_STRERROR 1" >>$@
	echo "#define HAVE_STRINGS_H 1" >>$@
	echo "#define HAVE_STRING_H 1" >>$@
	echo "#define HAVE_STRLCAT 1" >>$@
	echo "#define HAVE_STRLCPY 1" >>$@
	echo "#define HAVE_STRTOLL 1" >>$@
	echo "#define HAVE_SYS_STAT_H 1" >>$@
	echo "#define HAVE_SYS_TYPES_H 1" >>$@
	echo "#define HAVE_SETENV 1" >>$@
	echo "#define HAVE_UNISTD_H 1" >>$@
	echo "#define HAVE_UNSIGNED_LONG_LONG 1" >>$@
	echo "#define STDC_HEADERS 1" >>$@
	echo "#define HAVE_ALLOCA_H 1" >>$@
	echo "#define HAVE_ALLOCA 1" >>$@
	echo "#define HAVE_GRP_H 1" >>$@
	echo "#define HAVE_ERRNO_H 1" >>$@
	echo "#define HAVE_SYSEXITS_H 1" >>$@
	echo "#define C_STACK_GROWS_DOWNWARD 1" >>$@
ifdef GCHOOKS
	echo "#define C_GC_HOOKS" >>$@
endif
ifdef SYMBOLGC
	echo "#define C_COLLECT_ALL_SYMBOLS" >>$@
endif
ifneq ($(HACKED_APPLY),)
	echo "#define C_HACKED_APPLY" >>$@
endif
	cat chicken-defaults.h >>$@

include $(SRCDIR)/rules.make
-------------- next part --------------
# Makefile.cygwin - configuration for Linux -*- Makefile -*-
#
# Copyright (c) 2008-2014, The Chicken Team
# Copyright (c) 2007, Felix L. Winkelmann
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following
# conditions are met:
#
#   Redistributions of source code must retain the above copyright notice, this list of conditions and the following
#     disclaimer. 
#   Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
#     disclaimer in the documentation and/or other materials provided with the distribution. 
#   Neither the name of the author nor the names of its contributors may be used to endorse or promote
#     products derived from this software without specific prior written permission. 
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS
# OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
# AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.


ifneq ($(CONFIG),)
include $(CONFIG)
endif

SRCDIR = ./

# platform configuration

ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh)
HACKED_APPLY ?= 1
DLLSINPATH = 1

# options

SO = .dll
EXE = .exe

C_COMPILER = gcc
CXX_COMPILER = g++
RC_COMPILER = windres
LINKER = gcc
TARGET_RC_COMPILER ?= $(RC_COMPILER)

C_COMPILER_OPTIONS ?= -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H
ifdef DEBUGBUILD
C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused
else
ifdef OPTIMIZE_FOR_SPEED
C_COMPILER_OPTIMIZATION_OPTIONS ?= -O3 -fomit-frame-pointer
else
C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer
endif
endif
C_COMPILER_SHARED_OPTIONS = -DPIC
LINKER_LINK_SHARED_LIBRARY_OPTIONS = -shared 
LINKER_LINK_SHARED_PROGRAM_OPTIONS = -Wl,--dll-search-prefix=cyg
LIBCHICKEN_SO_LINKER_OPTIONS = -Wl,--out-implib,lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX).dll.a \
	-Wl,--export-all-symbols \
	-Wl,--enable-auto-import \
	-Wl,--image-base=0x10000000 \
	-Wl,--dll \
	-Wl,--add-stdcall-alias \
	-Wl,--no-whole-archive

LIBRARIES = -lm 
LIBCHICKEN_IMPORT_LIBRARY = lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX).dll.a


# special files

CHICKEN_CONFIG_H = chicken-config.h
APPLY_HACK_OBJECT = apply-hack.$(ARCH)$(O)

# select default and internal settings

include $(SRCDIR)/defaults.make

LIBCHICKEN_SO_LIBRARIES = $(LIBRARIES)

chicken-config.h: chicken-defaults.h
	echo "/* GENERATED */" >$@
	echo "#define C_INSTALL_RC_COMPILER \"$(RC_COMPILER)\"" >>$@
	echo "#define C_TARGET_RC_COMPILER \"$(TARGET_RC_COMPILER)\"" >>$@
	echo "#define HAVE_DIRENT_H 1" >>$@
	echo "#define HAVE_INTTYPES_H 1" >>$@
	echo "#define HAVE_LIMITS_H 1" >>$@
	echo "#define HAVE_LONG_LONG 1" >>$@
	echo "#define HAVE_MEMMOVE 1" >>$@
	echo "#define HAVE_MEMORY_H 1" >>$@
	echo "#define HAVE_POSIX_POLL 1" >>$@
	echo "#define HAVE_SIGACTION 1" >>$@
	echo "#define HAVE_STDINT_H 1" >>$@
	echo "#define HAVE_STDLIB_H 1" >>$@
	echo "#define HAVE_STRERROR 1" >>$@
	echo "#define HAVE_STRINGS_H 1" >>$@
	echo "#define HAVE_STRING_H 1" >>$@
	echo "#define HAVE_STRLCAT 1" >>$@
	echo "#define HAVE_STRLCPY 1" >>$@
	echo "#define HAVE_STRTOLL 1" >>$@
	echo "#define HAVE_STRTOQ 1" >>$@
	echo "#define HAVE_SYS_STAT_H 1" >>$@
	echo "#define HAVE_SYS_TYPES_H 1" >>$@
	echo "#define HAVE_UNISTD_H 1" >>$@
	echo "#define HAVE_UNSIGNED_LONG_LONG 1" >>$@
	echo "#define STDC_HEADERS 1" >>$@
	echo "#define HAVE_ALLOCA 1" >>$@
	echo "#define HAVE_ALLOCA_H 1" >>$@
	echo "#define HAVE_GRP_H 1" >>$@
	echo "#define HAVE_ERRNO_H 1" >>$@
	echo "#define HAVE_SYSEXITS_H 1" >>$@
	echo "#define HAVE_DLFCN_H 1" >>$@
	echo "#define C_STACK_GROWS_DOWNWARD 1" >>$@
ifdef GCHOOKS
	echo "#define C_GC_HOOKS" >>$@
endif
ifdef SYMBOLGC
	echo "#define C_COLLECT_ALL_SYMBOLS" >>$@
endif
ifdef HACKED_APPLY
	echo "#define C_HACKED_APPLY" >>$@
endif
	cat chicken-defaults.h >>$@

include $(SRCDIR)/rules.make

From crossd at gmail.com  Tue Jun  3 04:52:12 2014
From: crossd at gmail.com (Dan Cross)
Date: Mon, 2 Jun 2014 14:52:12 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
Message-ID: <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>

On Mon, Jun 2, 2014 at 2:27 PM, Brantley Coile <brantley at coraid.com> wrote:

> Isn't it part of the nostalgia?
>

Perhaps.

But nostalgia aside, something I find interesting (and frankly a bit
distressing) is what seems to me to simply be an acceptance that it's all
going to end with Linux.  That is to say, no one ever seems to talk about
what will come *after* Linux.  Will Linus's kernel truly be the last kernel
anyone works on seriously?  Somehow I very much doubt that.  And yet, you
don't see a lot of talk about evolutionary paths beyond Linux; it's a sort
of tunnel vision.

For a while, it seemed like Plan 9 and/or Inferno could be the way forward,
but they seem to be all but dead.  What will be the next step forward?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/aea6337b/attachment.html>

From arnold at skeeve.com  Tue Jun  3 05:10:14 2014
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 02 Jun 2014 13:10:14 -0600
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
Message-ID: <201406021910.s52JAEMM025574@freefriends.org>

Dan Cross <crossd at gmail.com> wrote:

> But nostalgia aside, something I find interesting (and frankly a bit
> distressing) is what seems to me to simply be an acceptance that it's all
> going to end with Linux.  That is to say, no one ever seems to talk about
> what will come *after* Linux.  Will Linus's kernel truly be the last kernel
> anyone works on seriously?  Somehow I very much doubt that.  And yet, you
> don't see a lot of talk about evolutionary paths beyond Linux; it's a sort
> of tunnel vision.
>
> For a while, it seemed like Plan 9 and/or Inferno could be the way forward,
> but they seem to be all but dead.  What will be the next step forward?

Brantley can tell you that Plan 9 isn't dead, although the Labs aren't
really providiing the "central control" that Steve mentioned and which
is so valuable. 

There is even some innovation in the Plan 9 world, but much of it is
"researchy" - not something to run your enterprise on.  (At least, not
without a few very sharp gurus handy.) It seems like Plan 9 has been
stuck somewhere between V7 and 4.3BSD in terms of "solidity" for many
years now. This is rather sad.

Arnold


From cowan at mercury.ccil.org  Tue Jun  3 05:30:55 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 2 Jun 2014 15:30:55 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
Message-ID: <20140602193055.GC18282@mercury.ccil.org>

Dan Cross scripsit:

> But nostalgia aside, something I find interesting (and frankly a bit
> distressing) is what seems to me to simply be an acceptance that it's all
> going to end with Linux.  That is to say, no one ever seems to talk about
> what will come *after* Linux.  Will Linus's kernel truly be the last kernel
> anyone works on seriously?  Somehow I very much doubt that.  And yet, you
> don't see a lot of talk about evolutionary paths beyond Linux; it's a sort
> of tunnel vision.

This is like asking when there will be a new scientific discovery in some
field.  There will be a new kernel when someone decides, as Linus did, to
write a new kernel.  If it catches on, it may supplement or replace Linux.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Sir, I quite agree with you, but what are we two against so many?
    --George Bernard Shaw,
         to a man booing at the opening of _Arms and the Man_


From crossd at gmail.com  Tue Jun  3 05:54:28 2014
From: crossd at gmail.com (Dan Cross)
Date: Mon, 2 Jun 2014 15:54:28 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602193055.GC18282@mercury.ccil.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
 <20140602193055.GC18282@mercury.ccil.org>
Message-ID: <CAEoi9W7h+nGB3c917J01=wLPQe=vpRbwG0sj8KPH2cGpxURkSQ@mail.gmail.com>

On Mon, Jun 2, 2014 at 3:30 PM, John Cowan <cowan at mercury.ccil.org> wrote:

> Dan Cross scripsit:
>
> > But nostalgia aside, something I find interesting (and frankly a bit
> > distressing) is what seems to me to simply be an acceptance that it's all
> > going to end with Linux.  That is to say, no one ever seems to talk about
> > what will come *after* Linux.  Will Linus's kernel truly be the last
> kernel
> > anyone works on seriously?  Somehow I very much doubt that.  And yet, you
> > don't see a lot of talk about evolutionary paths beyond Linux; it's a
> sort
> > of tunnel vision.
>
> This is like asking when there will be a new scientific discovery in some
> field.


Forgive me, but I think that's a bit of an odd analogy (or perhaps an
indication that I did not adequately explain what I meant).  However, let
me run with it for a moment and rephrase my statement: there can only be a
discovery if one decides it's worth doing the sort of investigation that
would lead to a new discovery, and I wonder whether "we" still have that
kind of curiosity or drive.  Or has Linux become so entrenched that no one
can imagine bothering anymore?

There will be a new kernel when someone decides, as Linus did, to
> write a new kernel.  If it catches on, it may supplement or replace Linux.


To whit: it appears that "we" (for some large value of "we") have
collectively decided that it's not worth looking for a replacement for
Linux.  If nothing else, I find that interesting.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/29ccb321/attachment.html>

From cnehren+tuhs at pobox.com  Tue Jun  3 05:47:49 2014
From: cnehren+tuhs at pobox.com (Chris Nehren)
Date: Mon, 2 Jun 2014 15:47:49 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
Message-ID: <20140602194749.GA2463@behemoth>

On Mon, Jun 02, 2014 at 14:52:12 -0400, Dan Cross wrote:
> But nostalgia aside, something I find interesting (and frankly a bit
> distressing) is what seems to me to simply be an acceptance that it's all
> going to end with Linux.  That is to say, no one ever seems to talk about
> what will come *after* Linux.  Will Linus's kernel truly be the last kernel
> anyone works on seriously?  Somehow I very much doubt that.  And yet, you
> don't see a lot of talk about evolutionary paths beyond Linux; it's a sort
> of tunnel vision.

You (specifically) don't see a lot of evolutionary paths beyond
Linux because you're not looking for them.  There is a lot of
innovation happening in illumos and BSD.  Thanks to the
aforementioned rms, Linux has been about evangelism almost from
the start.  The illumos and BSD communities are more focused on
great engineering rather than proselytization.  Let Linux have
the fame; everyone who wants to do great work (that Linux users
will then want to steal, and then gripe about because of
licensing FUD) is elsewhere.

-- 
Chris Nehren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 907 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/09bd9da7/attachment.sig>

From dugo at xs4all.nl  Tue Jun  3 06:06:52 2014
From: dugo at xs4all.nl (Jacob Goense)
Date: Mon, 02 Jun 2014 22:06:52 +0200
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
Message-ID: <498a888e69bc1600ab199aeb40e0e485@xs4all.nl>

On 2014-06-02 16:25, Clem Cole wrote:
> Linus this would eventually need a compiler and pulled rms' suite.
> 
>  The funny part is that his University has 386BSD (aka 4.2 for the
> 386) at the time which did use the MMU, had networking and even the
> first step at X11.  At the time I had helped the guys get the AT disk
> driver working as I had access to all the Western Digital
> documentation.   But to get the code from CRSG, you needed at BSD
> license, which required an AT&T license.   Linus' university had one,
> but he did know know the magic ftp site to download or have access.
> 
> I've often wondered what would have happened if he had known about it.

AFAICT 386BSD port started out with 4.3BSD-Tahoe sources.

Jolitz pulled in GCC[1], and Linus would have run into the same 
compiler.
Did Jolitz even have much of a choice back in '89?

[1] - From the original project proposal for 386BSD
3.1. Language tools:

We will base our port on nascent language utilities from RMS's GNU
project (GCC & GAS & LD), which are fairly well fleshed-out but have
never been put to the acid test. Obviously, we will encounter and
bypass and/or fix compiler bugs. Until we find a dedicated compiler
participant who is familiar with GCC, the author will field all
compiler problems and be responsible for fixes and/or workarounds.

We think that GCC is an excellent compiler to work with, and hope that
our use of it will provide FSF with much useful feedback on fixes and
improvements.



From crossd at gmail.com  Tue Jun  3 06:23:03 2014
From: crossd at gmail.com (Dan Cross)
Date: Mon, 2 Jun 2014 16:23:03 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602194749.GA2463@behemoth>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
 <20140602194749.GA2463@behemoth>
Message-ID: <CAEoi9W7B6-m2Yxupar+LuE_J8kJn5chEOEAfwssQYWCOPiYg1g@mail.gmail.com>

On Mon, Jun 2, 2014 at 3:47 PM, Chris Nehren <cnehren+tuhs at pobox.com> wrote:

> On Mon, Jun 02, 2014 at 14:52:12 -0400, Dan Cross wrote:
> > But nostalgia aside, something I find interesting (and frankly a bit
> > distressing) is what seems to me to simply be an acceptance that it's all
> > going to end with Linux.  That is to say, no one ever seems to talk about
> > what will come *after* Linux.  Will Linus's kernel truly be the last
> kernel
> > anyone works on seriously?  Somehow I very much doubt that.  And yet, you
> > don't see a lot of talk about evolutionary paths beyond Linux; it's a
> sort
> > of tunnel vision.
>
> You (specifically) don't see a lot of evolutionary paths beyond
> Linux because you're not looking for them.


Well, without knowing me or a thing about me, that's a strong statement.

There is a lot of innovation happening in illumos and BSD.

[snip]


This is my point.  s/Linux/(Illumos|.*BSD)/ and the point remains largely
the same.

These aren't new systems trying out fundamentally new ideas; they're making
incremental improvements on things that have come before.  That's all well
and good (and it's nice to have an alternative to Linux specifically), but
building on a nearly 50 year old framework isn't particularly innovative,
despite claims to the contrary.  Now don't get me wrong, that framework
remains wildly useful, and so that work has value, but my question is more
generally whether anyone has the kind of drive to come up with the sort of
next generation system that Unix represented when Unix was new?  Things
like Plan 9 and Akaros are more along the lines of what I was thinking of:
mentioning *BSD or other such systems reinforces my thesis.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/5f4f1904/attachment.html>

From corky1951 at comcast.net  Tue Jun  3 07:08:15 2014
From: corky1951 at comcast.net (Charlie Kester)
Date: Mon, 2 Jun 2014 14:08:15 -0700
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
Message-ID: <20140602210815.GA25138@comcast.net>

On Mon 02 Jun 2014 at 11:52:12 PDT Dan Cross wrote:
>   On Mon, Jun 2, 2014 at 2:27 PM, Brantley Coile <[1]brantley at coraid.com>
>   wrote:
>
>     Isn't it part of the nostalgia?
>
>   Perhaps.
>   But nostalgia aside, something I find interesting (and frankly a bit
>   distressing) is what seems to me to simply be an acceptance that it's all
>   going to end with Linux.  That is to say, no one ever seems to talk about
>   what will come *after* Linux.  Will Linus's kernel truly be the last
>   kernel anyone works on seriously?  Somehow I very much doubt that.  And
>   yet, you don't see a lot of talk about evolutionary paths beyond Linux;
>   it's a sort of tunnel vision.
>   For a while, it seemed like Plan 9 and/or Inferno could be the way
>   forward, but they seem to be all but dead.  What will be the next step
>   forward?

The recent dustup over systemd does seem to have many people looking for
alternatives to the main Linux distros -- and perhaps to Linux itself.

There's an opportunity, but it isn't clear that anyone is prepared to 
seize it.


From dds at aueb.gr  Tue Jun  3 08:05:49 2014
From: dds at aueb.gr (Diomidis Spinellis)
Date: Tue, 03 Jun 2014 01:05:49 +0300
Subject: [TUHS] unix history git
In-Reply-To: <CAGSRWbhKJEHaxkV51R4TBYRvZRO5WycLn__PsV4pe+B9kQSKww@mail.gmail.com>
References: <CAGSRWbhKJEHaxkV51R4TBYRvZRO5WycLn__PsV4pe+B9kQSKww@mail.gmail.com>
Message-ID: <538CF53D.1090801@aueb.gr>

Thank you for bringing this up.  I first posted to the list about the 
project in February 2013 [1], and some of you helpfully supplied me 
login names I was looking for.

Over the past few weeks I managed to solve a difficult problem that was 
puzzling me, namely how to commit each release snapshot files 
incrementally, while also ensuring that git blame would work correctly 
across releases.  Having solved the problem, I created a working 
repository with a some key releases in it, and was waiting to tidy up a 
few loose ends before coming to the list for more help.

Now hat the cat is out of the bag, here are a few things I could need 
your help.

1. The login names of the following Bell Labs researchers
Charles B. Haley
E. Schmidt

2. The login names of the following Berkeley authors
A. R. Newton
Charles Haley
Colin L. Mc Master
Douglas Lanam
D. O. Pederson
Ellis Cohen
Earl T. Cohen
Ivan Maltz
Juan Porcar
Jeff Schriebman
Kurt Shoens
Len Edmondson
Olivier Roubine
R. Dowell
Ross Harvey
Richard Tuck
Robert Toxen
Susan L. Graham
Zhishun Alex Liu

3. The names corresponding to the following Berkeley ids
claudio
csvaf
denise
ecc
epg
evan
fitz
fortran
harrison
lam
opcode
orange
rt

4. The authors of a few relatively large contributions (the numbers are 
the changed lines associated with the specific release and corresponding 
total lines).

Research-V6
usr/source/sno 1606 1606
usr/source/cref/src 1448 1463

Research-V7
usr/src/games/chess 3985 3993
usr/games/ching.d 2366 2366
usr/src/cmd/cpp 1413 1417
usr/src/cmd/lpr 1318 1318
usr/src/libF77 1271 1271

1BSD
pcs 1800 1800
portlib 1701 1781
opcodes 1580 1580

3BSD
usr/src/sys/sys 8163 16488
usr/src/cmd/f77 5981 17252
usr/src/new/libI77uc 4379 5395
usr/src/cmd/versatec 3885 4271
usr/games/advfiles/cave 1772 1772
usr/games/quiz.k 1709 1709
usr/src/cmd/uucp 1358 7387
usr/src/sys/stand 1350 3382
usr/src/games/banner.c 1129 1129

5. Errors and omissions in the files that map file paths to authors. [2]

You can supply these things via the list, if you think they're of wider 
interest, through private email, or through git pull requests.

[1] http://minnie.tuhs.org/pipermail/tuhs/2013-February/002836.html
[2] 
https://github.com/dspinellis/unix-history-make/blob/master/src/author-path

Diomidis Spinellis

On 02/06/2014 21:41, Tim Newsham wrote:
> have you guys seen this?
> https://github.com/dspinellis/unix-history-repo
>
> (I'm not involved, just came across it by way of twitter)
>



From clemc at ccc.com  Tue Jun  3 08:47:18 2014
From: clemc at ccc.com (Clem Cole)
Date: Mon, 2 Jun 2014 18:47:18 -0400
Subject: [TUHS] unix history git
In-Reply-To: <538CF53D.1090801@aueb.gr>
References: <CAGSRWbhKJEHaxkV51R4TBYRvZRO5WycLn__PsV4pe+B9kQSKww@mail.gmail.com>
 <538CF53D.1090801@aueb.gr>
Message-ID: <5A14B477-ED7D-4A27-8CCE-86AAABCE09E6@ccc.com>

the late rich newton had three login's. arn newton and merkin

the late don Pederson was dop


btw. dop more than anyone else really is the father of what now call the open source 
movement.  

> On Jun 2, 2014, at 6:05 PM, Diomidis Spinellis <dds at aueb.gr> wrote:
> 
> Thank you for bringing this up.  I first posted to the list about the project in February 2013 [1], and some of you helpfully supplied me login names I was looking for.
> 
> Over the past few weeks I managed to solve a difficult problem that was puzzling me, namely how to commit each release snapshot files incrementally, while also ensuring that git blame would work correctly across releases.  Having solved the problem, I created a working repository with a some key releases in it, and was waiting to tidy up a few loose ends before coming to the list for more help.
> 
> Now hat the cat is out of the bag, here are a few things I could need your help.
> 
> 1. The login names of the following Bell Labs researchers
> Charles B. Haley
> E. Schmidt
> 
> 2. The login names of the following Berkeley authors
> A. R. Newton
> Charles Haley
> Colin L. Mc Master
> Douglas Lanam
> D. O. Pederson
> Ellis Cohen
> Earl T. Cohen
> Ivan Maltz
> Juan Porcar
> Jeff Schriebman
> Kurt Shoens
> Len Edmondson
> Olivier Roubine
> R. Dowell
> Ross Harvey
> Richard Tuck
> Robert Toxen
> Susan L. Graham
> Zhishun Alex Liu
> 
> 3. The names corresponding to the following Berkeley ids
> claudio
> csvaf
> denise
> ecc
> epg
> evan
> fitz
> fortran
> harrison
> lam
> opcode
> orange
> rt
> 
> 4. The authors of a few relatively large contributions (the numbers are the changed lines associated with the specific release and corresponding total lines).
> 
> Research-V6
> usr/source/sno 1606 1606
> usr/source/cref/src 1448 1463
> 
> Research-V7
> usr/src/games/chess 3985 3993
> usr/games/ching.d 2366 2366
> usr/src/cmd/cpp 1413 1417
> usr/src/cmd/lpr 1318 1318
> usr/src/libF77 1271 1271
> 
> 1BSD
> pcs 1800 1800
> portlib 1701 1781
> opcodes 1580 1580
> 
> 3BSD
> usr/src/sys/sys 8163 16488
> usr/src/cmd/f77 5981 17252
> usr/src/new/libI77uc 4379 5395
> usr/src/cmd/versatec 3885 4271
> usr/games/advfiles/cave 1772 1772
> usr/games/quiz.k 1709 1709
> usr/src/cmd/uucp 1358 7387
> usr/src/sys/stand 1350 3382
> usr/src/games/banner.c 1129 1129
> 
> 5. Errors and omissions in the files that map file paths to authors. [2]
> 
> You can supply these things via the list, if you think they're of wider interest, through private email, or through git pull requests.
> 
> [1] http://minnie.tuhs.org/pipermail/tuhs/2013-February/002836.html
> [2] https://github.com/dspinellis/unix-history-make/blob/master/src/author-path
> 
> Diomidis Spinellis
> 
>> On 02/06/2014 21:41, Tim Newsham wrote:
>> have you guys seen this?
>> https://github.com/dspinellis/unix-history-repo
>> 
>> (I'm not involved, just came across it by way of twitter)
>> 
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From cowan at mercury.ccil.org  Tue Jun  3 09:37:21 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 2 Jun 2014 19:37:21 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAEoi9W7h+nGB3c917J01=wLPQe=vpRbwG0sj8KPH2cGpxURkSQ@mail.gmail.com>
References: <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
 <20140602193055.GC18282@mercury.ccil.org>
 <CAEoi9W7h+nGB3c917J01=wLPQe=vpRbwG0sj8KPH2cGpxURkSQ@mail.gmail.com>
Message-ID: <20140602233721.GF18282@mercury.ccil.org>

Dan Cross scripsit:

> > There will be a new kernel when someone decides, as Linus did, to
> > write a new kernel.  If it catches on, it may supplement or replace Linux.
> 
> To whit: it appears that "we" (for some large value of "we") have
> collectively decided that it's not worth looking for a replacement for
> Linux.  If nothing else, I find that interesting.

It doesn't matter how many people decide not to do it, any more than it
matters how many people decide not to try to find a replacement for the
Standard Model.  It only takes one to decide *to* do it.  Of course,
some people may decide and never do it, or never finish it, or be mute
inglorious Miltons who are never heard of, or who are heard of but fail
to take over the world.

All anyone can do is either do it themselves or wait for someone else
to do so.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
If I have not seen as far as others, it is because giants were standing
on my shoulders.  --Hal Abelson


From tim.newsham at gmail.com  Tue Jun  3 10:37:52 2014
From: tim.newsham at gmail.com (Tim Newsham)
Date: Mon, 2 Jun 2014 14:37:52 -1000
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
Message-ID: <CAGSRWbgKp8DoYJrubUR8E4NyuouZHnU9C_pNc=jfdxzAJThOSw@mail.gmail.com>

It would be nice if we end up moving towards
something with a solid theoretical underpinning..
seL4 comes to mind. I'd be happy to trade off some
performance for some security and strongly enforced
modularity. There's still lots to be done (sel4 is just
a small microkernel (needed: drivers, filesystems,
memory subsystems, etc), and there's little point in having
a proven microkernel if you don't keep building up
strong software on top of that foundation).
</increasinglyOffTopic>

On Mon, Jun 2, 2014 at 8:52 AM, Dan Cross <crossd at gmail.com> wrote:
> On Mon, Jun 2, 2014 at 2:27 PM, Brantley Coile <brantley at coraid.com> wrote:
>>
>> Isn't it part of the nostalgia?
>
>
> Perhaps.
>
> But nostalgia aside, something I find interesting (and frankly a bit
> distressing) is what seems to me to simply be an acceptance that it's all
> going to end with Linux.  That is to say, no one ever seems to talk about
> what will come *after* Linux.  Will Linus's kernel truly be the last kernel
> anyone works on seriously?  Somehow I very much doubt that.  And yet, you
> don't see a lot of talk about evolutionary paths beyond Linux; it's a sort
> of tunnel vision.
>
> For a while, it seemed like Plan 9 and/or Inferno could be the way forward,
> but they seem to be all but dead.  What will be the next step forward?
>
>         - Dan C.
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>



-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com


From crossd at gmail.com  Tue Jun  3 11:24:39 2014
From: crossd at gmail.com (Dan Cross)
Date: Mon, 2 Jun 2014 21:24:39 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602233721.GF18282@mercury.ccil.org>
References: <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
 <20140602193055.GC18282@mercury.ccil.org>
 <CAEoi9W7h+nGB3c917J01=wLPQe=vpRbwG0sj8KPH2cGpxURkSQ@mail.gmail.com>
 <20140602233721.GF18282@mercury.ccil.org>
Message-ID: <CAEoi9W5t7TCn=_B2_-xwgWpTT556p_0rPV1uwT1x=LZDVgGeKw@mail.gmail.com>

You are, of course, free to not find it interesting in the way that I do.
 :-)


On Mon, Jun 2, 2014 at 7:37 PM, John Cowan <cowan at mercury.ccil.org> wrote:

> Dan Cross scripsit:
>
> > > There will be a new kernel when someone decides, as Linus did, to
> > > write a new kernel.  If it catches on, it may supplement or replace
> Linux.
> >
> > To whit: it appears that "we" (for some large value of "we") have
> > collectively decided that it's not worth looking for a replacement for
> > Linux.  If nothing else, I find that interesting.
>
> It doesn't matter how many people decide not to do it, any more than it
> matters how many people decide not to try to find a replacement for the
> Standard Model.  It only takes one to decide *to* do it.  Of course,
> some people may decide and never do it, or never finish it, or be mute
> inglorious Miltons who are never heard of, or who are heard of but fail
> to take over the world.
>
> All anyone can do is either do it themselves or wait for someone else
> to do so.
>
> --
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> If I have not seen as far as others, it is because giants were standing
> on my shoulders.  --Hal Abelson
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/77f8a708/attachment.html>

From brantley at coraid.com  Tue Jun  3 11:45:40 2014
From: brantley at coraid.com (Brantley Coile)
Date: Tue, 3 Jun 2014 01:45:40 +0000
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <201406021910.s52JAEMM025574@freefriends.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
 <201406021910.s52JAEMM025574@freefriends.org>
Message-ID: <B3159E8E-4A64-454A-B1DD-2FAA944FC9B4@coraid.com>


On Jun 2, 2014, at 3:10 PM, arnold at skeeve.com wrote:

> Brantley can tell you that Plan 9 isn't dead, although the Labs aren't
> really providiing the "central control" that Steve mentioned and which
> is so valuable. 

Plan 9 will be my development system for the foreseeable future.  I built the PIX on BSDI using all the tools from the Labs that I could get my hands on, such as sam(1), rc(1) (from Byron), mk(1), and 9win.  I shifted the group to real Plan 9 in 1995, when it became available.  I used it to build Coraid and I’ll use it for any startups in the future.  I get more done faster using it than any other system I’ve tried.  

I have always kept an independent version running and pick and choose what goes into it.  For example, I still run a Ken Thompson file server, even after it was replaced with “better” technology.  Plan 9’s stability is one of the things I greatly value; some parts of our system have uptime’s longer than two years.  In the past few years, Erik Quanstrom has been Coraid's keeper of our version of Plan 9.  For me, he still is.  He has worked, with others, to keep the drivers current and adjust things to the changes in hardware.  We run a 64 version, for example, on the latest Intel hardware.

It might have a very tiny user base, but they will pry Plan 9 out of my cold dead fingers.  (That’s a Mike O’Dell reference.)  So it will remain alive.

Post script.  If you want a mindblowingly elegant and beautiful system, study the Oberon system from the 1980’s by Niklaus Wirth.  It inspired the Plan 9 editor acme(1).  I’ve seen nothing that compares to it’s clarity of thought.  Interestingly, Ken Thompson and Niklaus Wirth were both students at Berkeley at same time.  I wonder if Harry Huskey’s values are reflected in their work.

Brantley



From cowan at mercury.ccil.org  Tue Jun  3 12:16:13 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 2 Jun 2014 22:16:13 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAEoi9W5t7TCn=_B2_-xwgWpTT556p_0rPV1uwT1x=LZDVgGeKw@mail.gmail.com>
References: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
 <20140602193055.GC18282@mercury.ccil.org>
 <CAEoi9W7h+nGB3c917J01=wLPQe=vpRbwG0sj8KPH2cGpxURkSQ@mail.gmail.com>
 <20140602233721.GF18282@mercury.ccil.org>
 <CAEoi9W5t7TCn=_B2_-xwgWpTT556p_0rPV1uwT1x=LZDVgGeKw@mail.gmail.com>
Message-ID: <20140603021613.GG18282@mercury.ccil.org>

Dan Cross scripsit:

> You are, of course, free to not find it interesting in the way that I do.

It's not that, I just think you are asking for a prediction of the inherently
unpredictable.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
I amar prestar aen, han mathon ne nen,    http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith.  --Galadriel, LOTR:FOTR


From crossd at gmail.com  Tue Jun  3 12:18:14 2014
From: crossd at gmail.com (Dan Cross)
Date: Mon, 2 Jun 2014 22:18:14 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140603021613.GG18282@mercury.ccil.org>
References: <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
 <20140602193055.GC18282@mercury.ccil.org>
 <CAEoi9W7h+nGB3c917J01=wLPQe=vpRbwG0sj8KPH2cGpxURkSQ@mail.gmail.com>
 <20140602233721.GF18282@mercury.ccil.org>
 <CAEoi9W5t7TCn=_B2_-xwgWpTT556p_0rPV1uwT1x=LZDVgGeKw@mail.gmail.com>
 <20140603021613.GG18282@mercury.ccil.org>
Message-ID: <CAEoi9W7pytvp8jYHUbyeNtMfrTgoXkeceOsEc9RYoXQiOcgxnw@mail.gmail.com>

On Mon, Jun 2, 2014 at 10:16 PM, John Cowan <cowan at mercury.ccil.org> wrote:

> Dan Cross scripsit:
> > You are, of course, free to not find it interesting in the way that I do.
>
> It's not that, I just think you are asking for a prediction of the
> inherently
> unpredictable.


I'm not asking for any prediction.  I'm merely stating that it seems to me
that people aren't interested in these sorts of things anymore.  I find
that interesting (and a little sad).

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/6a676fdd/attachment.html>

From reed at reedmedia.net  Tue Jun  3 14:07:54 2014
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Mon, 2 Jun 2014 23:07:54 -0500 (CDT)
Subject: [TUHS] unix history git
In-Reply-To: <538CF53D.1090801@aueb.gr>
References: <CAGSRWbhKJEHaxkV51R4TBYRvZRO5WycLn__PsV4pe+B9kQSKww@mail.gmail.com>
 <538CF53D.1090801@aueb.gr>
Message-ID: <alpine.NEB.2.02.1406022130290.4696@t1.m.reedmedia.net>

On Tue, 3 Jun 2014, Diomidis Spinellis wrote:

> 2. The login names of the following Berkeley authors
> A. R. Newton

What code?

> Charles Haley

chuck (per 1BSD's winfo, sh.1, cpall.6, where.6, whoison.6)

> Douglas Lanam

What code?

> D. O. Pederson

Real name is probably "Donald". But what code?

> Ellis Cohen

cohen (per 1BSD's where.6 ; I don't think is Earl)

> Juan Porcar

What specific code file for Juan Porcar?

> Jeff Schriebman

jeff (per 1BSD's winfo)

> Kurt Shoens

kurt (per 1BSD's winfo, mvall.6, whoison.6)

> R. Dowell

Richard "Dick" Dowell of Hewlett Packard.

> Ross Harvey

UCSF Computer Graphics Laboratory

> Richard Tuck

tuck (per 2BSD netintro.n)

> 3. The names corresponding to the following Berkeley ids
> claudio

The login "dlw" included DLW as part of SCCS commit messages. The 
claudio entry also says "DLW". So probably David L. Wasley.

> csvaf

Alastair Fyfe

> denise

Denise Draper

> ecc

Eric C. Cooper  (login name also is "cooper" later)

> epg
> evan
> fitz

Dan Fitzpatrick

> fortran

I don't see this one.

> harrison

Mike Harrison or  Susan Graham Harrison (except I don't know timing for 
that name).

> lam

Karen Lam of BBN

> opcode

Mark Opperman

> orange

Carol Orange

> rt

I also don't find "rt"

> 1BSD
> pcs 1800 1800

One of the files says "Wirth" and note that other files have spellings 
like "funktion", "prozedure", "konstant". So maybe all this is from 
Wirth?

> portlib 1701 1781

I think this portlib is from Eric Allman.

> opcodes 1580 1580

I guess Thompson, Haley or Joy.

> 3BSD

I assume you are refering to parts not from 32V...

> usr/src/sys/sys 8163 16488

I guess Babaoglu, maybe Juan Porcar, and Joy. Note that the TODO 
mentions code given to Joy.

> usr/src/cmd/f77 5981 17252

I think some of the improvements came from the upstream (November 1978 
1.16 vs. January 1980's 2.00).

> usr/src/new/libI77uc 4379 5395

Files say originally P. Weinberger and modified by David Wasley.

> usr/src/cmd/versatec 3885 4271

sidebyside was written by Joy (per Len Edmondson personal 
correspondence).

> usr/games/advfiles/cave 1772 1772

It was common that some source for games weren't included.

Says originally developed by Willie Crowther and most features added by 
Don Woods (don @ su-ai). And the file says to ask "ark" for questions. I 
think was in a group called MHTSA (but I don't kno what means).

> usr/src/cmd/uucp 1358 7387

Maybe Dave Nowitz?

> usr/src/sys/stand 1350 3382

Some of this is just from 32V. I can only guess the changes were from 
Joy.

> usr/src/games/banner.c 1129 1129

Mark Horton (see corresponding man page!)

(As a reminder to list readers ... I am authoring a very detailed book 
covering the history of Berkeley Unix. I have done interviews either by 
email, phone, and some in person with over 80 of the very 
early contributors.)


From emu at e-bbes.com  Tue Jun  3 22:11:21 2014
From: emu at e-bbes.com (emanuel stiebler)
Date: Tue, 03 Jun 2014 14:11:21 +0200
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu>
References: <20140602033405.E0EA818C0AD@mercury.lcs.mit.edu>
Message-ID: <538DBB69.2000206@e-bbes.com>

On 2014-06-02 05:34, Noel Chiappa wrote:

> I have recently discovered (in my basement!) two sets of full dump tapes
> (1/2" magtape) of what I think are the whole filesystem, so if I can find a
> way to get them read, we'll have the V6 fsck - and much more besides (such
> as a TCP/IP for V6). So I think you may soon get your wish!

IIRC, we had a list of people somewhere on TUHS/PUPS, which still can 
read & write tapes. We had this service for people, who couldn't pull 
the whole archive through the net, so we send out tapes ...

Cheers

P.S. Sorry, can't find a link for it at the moment



From beebe at math.utah.edu  Wed Jun  4 02:38:21 2014
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Tue, 3 Jun 2014 10:38:21 -0600 (MDT)
Subject: [TUHS] Bugs in V6 'dcheck'
In-Reply-To: <201405312324.s4VNOvFV028181@stowe.cs.dartmouth.edu>
Message-ID: <CMM.0.95.0.1401813501.beebe@psi.math.utah.edu>

Doug McIlroy <doug at cs.dartmouth.edu> wrote on Sat, 31 May 2014
19:24:57 -0400:

>> ...
>> In an idle moment one day, Dennis fed a huge line of input to most
>> everything in /bin. To the surprise of nobody, including Dennis, lots
>> of programs crashed. We WERE surprised a few years later, when a
>> journal published this fact as a research result. Does anybody
>> remember who published that deep new insight and/or where?
>> ...

I suspect that two relevant papers that Doug is recalling are these (I
routinely use their fuzz-test code on my own software):

@String{j-CACM                  = "Communications of the ACM"}

@Article{Miller:1990:ESR,
  author =       "Barton P. Miller and Lars Fredriksen and Bryan So",
  title =        "An empirical study of the reliability of {UNIX}
                 utilities",
  journal =      j-CACM,
  volume =       "33",
  number =       "12",
  pages =        "32--44",
  month =        dec,
  year =         "1990",
  CODEN =        "CACMA2",
  ISSN =         "0001-0782 (print), 1557-7317 (electronic)",
  ISSN-L =       "0001-0782",
  bibdate =      "Wed Sep 25 09:24:48 2002",
  bibsource =    "ftp://ftp.ira.uka.de/pub/bibliography/Misc/IMMD_IV.bib;
                 http://www.acm.org/pubs/toc/;
                 http://www.math.utah.edu/pub/tex/bib/cacm1990.bib",
  note =         "This is a fascinating paper on what happens when
                 random input streams are fed into important UNIX
                 utilities on several commercial UNIX systems. In some
                 cases, the tests were able to crash the entire
                 operating system. In 1995, a (sadly, unpublished)
                 followup study showed that many of the failures
                 diagnosed in 1990 still had not been repaired in the
                 commercial systems, and that the GNU implementations
                 were generally more robust. Both 1990 and 1995 papers,
                 and the fuzz-generating software, are available at the
                 authors' FTP site at
                 \path|ftp://grilled.cs.wisc.edu/technical_papers/fuzz.ps|
                 and
                 \path|ftp://grilled.cs.wisc.edu/technical_papers/fuzz-revisited.ps|.",
  URL =          "ftp://grilled.cs.wisc.edu/technical_papers/fuzz-revisited.ps;
                 ftp://grilled.cs.wisc.edu/technical_papers/fuzz.ps;
                 http://www.acm.org/pubs/toc/Abstracts/0001-0782/96279.html",
  acknowledgement = ack-nhfb,
  journal-URL =  "http://portal.acm.org/browse_dl.cfm?idx=J79",
  keywords =     "design; reliability; security",
  note2 =        "[25-Sep-2002]: The fuzz software archive has been
                 moved to
                 \path|ftp://ftp.cs.wisc.edu/pub/paradyn/fuzz/|, and the
                 technical reports to
                 \path|ftp://ftp.cs.wisc.edu/pub/paradyn/technical_papers/fuzz*|.",
  subject =      "{\bf D.4.5}: Software, OPERATING SYSTEMS, Reliability.
                 {\bf D.4.0}: Software, OPERATING SYSTEMS, General,
                 UNIX. {\bf D.4.9}: Software, OPERATING SYSTEMS, Systems
                 Programs and Utilities. {\bf D.2.5}: Software, SOFTWARE
                 ENGINEERING, Testing and Debugging.",
}

@String{j-OPER-SYS-REV          = "Operating Systems Review"}

@Article{Miller:2007:ESR,
  author =       "Barton P. Miller and Gregory Cooksey and Fredrick
                 Moore",
  title =        "An empirical study of the robustness of {MacOS}
                 applications using random testing",
  journal =      j-OPER-SYS-REV,
  volume =       "41",
  number =       "1",
  pages =        "78--86",
  month =        jan,
  year =         "2007",
  CODEN =        "OSRED8",
  DOI =          "http://doi.acm.org/10.1145/1228291.1228308",
  ISSN =         "0163-5980 (print), 1943-586X (electronic)",
  ISSN-L =       "0163-5980",
  bibdate =      "Fri Jun 20 17:15:27 MDT 2008",
  bibsource =    "http://portal.acm.org/;
                 http://www.math.utah.edu/pub/tex/bib/opersysrev.bib",
  abstract =     "We report on the fourth in a series of studies on the
                 reliability of application programs in the face of
                 random input. Over the previous 15 years, we have
                 studied the reliability of UNIX command line and
                 X-Window based (GUI) applications and Windows
                 applications. In this study, we apply our fuzz testing
                 techniques to applications running on the Mac OS X
                 operating system. We continue to use a simple, or even
                 simplistic technique: unstructured black-box random
                 testing, considering a failure to be a crash or hang.
                 As in the previous three studies, the technique is
                 crude but seems to be effective in locating bugs in
                 real programs. We tested the reliability of 135
                 command-line UNIX utilities and thirty graphical
                 applications on Mac OS X by feeding random input to
                 each. We report on application failures --- crashes
                 (dumps core) or hangs (loops indefinitely) --- and, where
                 source code is available, we identify the causes of
                 these failures and categorize them. Our testing crashed
                 only 7\% of the command-line utilities, a considerably
                 lower rate of failure than observed in almost all cases
                 of previous studies. We found the GUI-based
                 applications to be less reliable: of the thirty that we
                 tested, only eight did not crash or hang. Twenty others
                 crashed, and two hung. These GUI results were
                 noticeably worse than either of the previous Windows
                 (Win32) or UNIX (X-Windows) studies.",
  acknowledgement = ack-nhfb,
  fjournal =     "ACM SIGOPS Operating Systems Review",
  journal-URL =  "http://portal.acm.org/browse_dl.cfm?idx=J597",
  keywords =     "fuzz; random testing",
}

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From beebe at math.utah.edu  Wed Jun  4 03:33:10 2014
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Tue, 3 Jun 2014 11:33:10 -0600 (MDT)
Subject: [TUHS] Bugs in V6 'dcheck'
Message-ID: <CMM.0.95.0.1401816790.beebe@psi.math.utah.edu>

I noted just as I sent my previous posting with two references to
fuzz-test papers that the abstract of the second mentions two earlier
ones. 

I've just tracked them down, and added them to various bibliographies.
Here are short references to them:

	Fuzz Revisited: A Re-examination of the Reliability of UNIX
	Utilities and Services
	ftp://ftp.cs.wisc.edu/pub/techreports/1995/TR1268.pdf

	An Empirical Study of the Robustness of MacOS Applications
	Using Random Testing
	http://dx.doi.org/10.1145/1228291.1228308

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From scj at yaccman.com  Wed Jun  4 04:48:25 2014
From: scj at yaccman.com (scj at yaccman.com)
Date: Tue, 3 Jun 2014 11:48:25 -0700
Subject: [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6
 'dcheck'))
In-Reply-To: <CAEoi9W7B6-m2Yxupar+LuE_J8kJn5chEOEAfwssQYWCOPiYg1g@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
 <20140602194749.GA2463@behemoth>
 <CAEoi9W7B6-m2Yxupar+LuE_J8kJn5chEOEAfwssQYWCOPiYg1g@mail.gmail.com>
Message-ID: <57e9892e6ab11d0d12d0cea5bf6e8d6b.squirrel@webmail.yaccman.com>

Well, I'm sure my biases are showing, but I see the Kernel as a means for
supplying features for a model of computation, and the programming
language as the delivery vehicle for that model of computation.  And in my
view, C/C++ is far more obsolete than Linux.

Hardware has left software in the dust.  It is quite feasible to produce a
chip with 1000 or 10,000 processors on it, each with a bit of memory and a
communication fabric.  That's what tomorrow's technology is giving us. 
Multicore and named threads are just not going to cut it when using such a
system.  A central supplier of any service is a bottleneck.  We've got to
write our software to act more like an ant farm than a military hierarchy.

Otherwise said, we have to learn to think different.  Very different.  And
the hardest part of that is letting go of the old ways of thinking. 
Perhaps encroaching senility is help in this...

Steve



From lm at mcvoy.com  Wed Jun  4 10:57:38 2014
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 3 Jun 2014 17:57:38 -0700
Subject: [TUHS] unix history git
In-Reply-To: <alpine.NEB.2.02.1406022130290.4696@t1.m.reedmedia.net>
References: <CAGSRWbhKJEHaxkV51R4TBYRvZRO5WycLn__PsV4pe+B9kQSKww@mail.gmail.com>
 <538CF53D.1090801@aueb.gr>
 <alpine.NEB.2.02.1406022130290.4696@t1.m.reedmedia.net>
Message-ID: <20140604005738.GE17402@mcvoy.com>

> (As a reminder to list readers ... I am authoring a very detailed book 
> covering the history of Berkeley Unix. I have done interviews either by 
> email, phone, and some in person with over 80 of the very 
> early contributors.)

Very interesting.  Does your research extend into Sun?  Because wnj went
there and SunOS (not that Solaris stuff) was a "better BSD than BSD".
mmap, vnodes, lots of very cool OS stuff happened at Sun that did not
happen at Berkeley.  No disrespect to Berkeley, they got the ball rolling,
in some ways they were the Linux of the day, moving stuff forward while
the rest of the world stalled.

What was that Ken quote?  Something about cat went to Berkeley and came
back waving tails?  Something like that?  Whatever, I've been part of Unix
dev for a long time and I'm painfully aware of the pushback that happens
when people want to make things better.  Berkeley made Unix better.
Sun made it hugely better in my opinion.  I was there at the tail end,
you don't want to talk to me, you want to talk to wnj, rusty, moran, srk.
They did some cool stuff.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From lm at mcvoy.com  Wed Jun  4 11:10:11 2014
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 3 Jun 2014 18:10:11 -0700
Subject: [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6
 'dcheck'))
In-Reply-To: <57e9892e6ab11d0d12d0cea5bf6e8d6b.squirrel@webmail.yaccman.com>
References: <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
 <20140602194749.GA2463@behemoth>
 <CAEoi9W7B6-m2Yxupar+LuE_J8kJn5chEOEAfwssQYWCOPiYg1g@mail.gmail.com>
 <57e9892e6ab11d0d12d0cea5bf6e8d6b.squirrel@webmail.yaccman.com>
Message-ID: <20140604011011.GF17402@mcvoy.com>

First, let me say how cool it is to be replying to the guy who did yacc.
I've used it for decades, thank you for that.

I was at SGI when they did the Origin servers, the architecture (as I
remember it) was a board with 2 CPUS, some local memory, and an connection
to a hypercube style of memory.  An interesting aside is that this is
where I learned that infinitely large packets in a network are infinitely
stupid because you have to buffer a packet if the outgoing port is busy.
I used to be a fan of big packets on ethernet, that system taught me
that ethernet is just fine.  The Origin "network" had ~32 byte packets.
Buffering those was "easy".

The problem with the lots-of-cpus design is that memory latency goes up.
It was OK for local memory, it was not OK for remote memory.  Don't get
me wrong, SGI did a really great job at it, but when you compare a bunch
of networked boxes with the SMP model SGI had, SGI won on jobs that needed
shared memory, the bunch of networked boxes kicked ass on everything else.
Cross reference: google.  Intel's test harness.  And a bunch of others.
When you are benchmarking against a 10,000 node cluster and the cluster
is winning, yeah, you need to rethink what you are doing.

I've copied Greg Chesson, you guys should know him, he's ex Bell Labs,
he can correct my ramblings, I worked for him at SGI.

--lm

On Tue, Jun 03, 2014 at 11:48:25AM -0700, scj at yaccman.com wrote:
> Well, I'm sure my biases are showing, but I see the Kernel as a means for
> supplying features for a model of computation, and the programming
> language as the delivery vehicle for that model of computation.  And in my
> view, C/C++ is far more obsolete than Linux.
> 
> Hardware has left software in the dust.  It is quite feasible to produce a
> chip with 1000 or 10,000 processors on it, each with a bit of memory and a
> communication fabric.  That's what tomorrow's technology is giving us. 
> Multicore and named threads are just not going to cut it when using such a
> system.  A central supplier of any service is a bottleneck.  We've got to
> write our software to act more like an ant farm than a military hierarchy.
> 
> Otherwise said, we have to learn to think different.  Very different.  And
> the hardest part of that is letting go of the old ways of thinking. 
> Perhaps encroaching senility is help in this...
> 
> Steve


From lars at nocrew.org  Wed Jun  4 15:53:50 2014
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 04 Jun 2014 07:53:50 +0200
Subject: [TUHS] unix history git
In-Reply-To: <20140604005738.GE17402@mcvoy.com> (Larry McVoy's message of
 "Tue\, 3 Jun 2014 17\:57\:38 -0700")
References: <CAGSRWbhKJEHaxkV51R4TBYRvZRO5WycLn__PsV4pe+B9kQSKww@mail.gmail.com>
 <538CF53D.1090801@aueb.gr>
 <alpine.NEB.2.02.1406022130290.4696@t1.m.reedmedia.net>
 <20140604005738.GE17402@mcvoy.com>
Message-ID: <85y4xdmd8x.fsf@junk.nocrew.org>

Larry McVoy wrote:
> What was that Ken quote?  Something about cat went to Berkeley and
> came back waving tails?

Flags.


From lm at mcvoy.com  Thu Jun  5 00:31:45 2014
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 4 Jun 2014 07:31:45 -0700
Subject: [TUHS] SunOS 4.1.1 or later?
Message-ID: <20140604143145.GA30260@mcvoy.com>

Does anyone have that running on anything?  If so, I'd like a copy of the
lint libraries, probably /usr/lib/ll* or something like that.  

It's not well known but I spent a pile of time creating lint libraries for
pure BSD, System V, etc, so you could lint your code against a target and
know if you let some non-standard stuff creep in.

I suppose I could fire up a Sun3 emulator like this and find them:

http://www.abiyo.net/retrocomputing/installingsunos411tosun3emulatedintme08onlinux

If someone has a SunOS 4.1.1 box on the net and can give me a login (non-root)
that would be appreciated.

Thanks,

--lm


From mah at mhorton.net  Thu Jun  5 01:41:00 2014
From: mah at mhorton.net (Mary Ann Horton)
Date: Wed, 04 Jun 2014 08:41:00 -0700
Subject: [TUHS] SunOS 4.1.3
In-Reply-To: <20140604143145.GA30260@mcvoy.com>
References: <20140604143145.GA30260@mcvoy.com>
Message-ID: <20140604084100.2019735cou0nxkp8@webmail.mhorton.net>

I would love to find a CD or ISO of SunOS 4.1.3 (whichever was the  
latest before Solaris 2)?

Thanks,

   Mary Ann



From dds at aueb.gr  Thu Jun  5 04:45:36 2014
From: dds at aueb.gr (Diomidis Spinellis)
Date: Wed, 04 Jun 2014 21:45:36 +0300
Subject: [TUHS] unix history git
In-Reply-To: <alpine.NEB.2.02.1406022130290.4696@t1.m.reedmedia.net>
References: <CAGSRWbhKJEHaxkV51R4TBYRvZRO5WycLn__PsV4pe+B9kQSKww@mail.gmail.com>
 <538CF53D.1090801@aueb.gr>
 <alpine.NEB.2.02.1406022130290.4696@t1.m.reedmedia.net>
Message-ID: <538F6950.9000909@aueb.gr>

Thank you!  I have committed your contribution through 
https://github.com/dspinellis/unix-history-make/commit/830221fb3d20395f723a584a48e3323ba400ffdb

Regarding your questions, please see my responses below.

Kind regards,

Diomidis Spinellis

On 03/06/2014 07:07, Jeremy C. Reed wrote:
> On Tue, 3 Jun 2014, Diomidis Spinellis wrote:
[...]
>> 2. The login names of the following Berkeley authors
>> A. R. Newton
>
> What code?

3bsd/usr/man/man1/spice.1:``Users Guide for Spice2'' by D. Dowell, A. R. 
Newton,

>> Douglas Lanam
>
> What code?

3bsd/usr/man/man1/apl.1:Ken Thompson, Ross Harvey, Douglas Lanam

>> Juan Porcar
>
> What specific code file for Juan Porcar?

3bsd/usr/src/sys/sys/makefile:# Virtual UNIX Mods by Ozalp Babaoglu, 
Bill Joy and Juan Porcar
3bsd/usr/src/sys/sys/makefile.bak:#     Virtual UNIX Mods by Ozalp 
Babaoglu, Bill Joy and Juan Porcar
3bsd/usr/doc/vmunix/design.t:Juan Porcar




From lm at mcvoy.com  Thu Jun  5 05:18:27 2014
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 4 Jun 2014 12:18:27 -0700
Subject: [TUHS] SunOS 4.1.1 or later?
In-Reply-To: <20140604143145.GA30260@mcvoy.com>
References: <20140604143145.GA30260@mcvoy.com>
Message-ID: <20140604191827.GA1461@mcvoy.com>

I found 'em, thanks.

On Wed, Jun 04, 2014 at 07:31:45AM -0700, Larry McVoy wrote:
> Does anyone have that running on anything?  If so, I'd like a copy of the
> lint libraries, probably /usr/lib/ll* or something like that.  
> 
> It's not well known but I spent a pile of time creating lint libraries for
> pure BSD, System V, etc, so you could lint your code against a target and
> know if you let some non-standard stuff creep in.
> 
> I suppose I could fire up a Sun3 emulator like this and find them:
> 
> http://www.abiyo.net/retrocomputing/installingsunos411tosun3emulatedintme08onlinux
> 
> If someone has a SunOS 4.1.1 box on the net and can give me a login (non-root)
> that would be appreciated.
> 
> Thanks,
> 
> --lm
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

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


From lm at mcvoy.com  Thu Jun  5 10:43:58 2014
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 4 Jun 2014 17:43:58 -0700
Subject: [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6
 'dcheck'))
In-Reply-To: <CAMN4JoRuqqTsaqnJZX37ej_3+poQzupk3FegV2Jc=w5wz55iUg@mail.gmail.com>
References: <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
 <20140602194749.GA2463@behemoth>
 <CAEoi9W7B6-m2Yxupar+LuE_J8kJn5chEOEAfwssQYWCOPiYg1g@mail.gmail.com>
 <57e9892e6ab11d0d12d0cea5bf6e8d6b.squirrel@webmail.yaccman.com>
 <20140604011011.GF17402@mcvoy.com>
 <CAMN4JoRuqqTsaqnJZX37ej_3+poQzupk3FegV2Jc=w5wz55iUg@mail.gmail.com>
Message-ID: <20140605004358.GD3313@mcvoy.com>

Hey Greg,

It's "tuhs" not "tubs" and it stands for The Unix Historical Society so far
as I know.  Lots of Bell Labs and other folks on the list, it's a fun walk
down memory lane, you should join.

What started the conversation was someone musing on whether Linux is the 
end of OS development.  Steve was talking about problems that SGI worked 
on so I wanted to point out that there might be something to mine there.

--lm

On Tue, Jun 03, 2014 at 08:42:56PM -0700, Greg Chesson wrote:
> Hi,
> 
> I certainly know scj from Murray Hill.  Not sure who is tubs.
> 
> Distributed and parallel hardware has evolved far beyond the ability
> of most sw.  Everyone agrees, I think; and, GPUs just make it more so.
> 
> On the other hand, cpu architecture remains classic Von Neumann
> with registers, alus, and familiar memory hierarchies. Close to the
> hardware where instructions are visible, there is not much change.
> And I think there are compelling technical reasons on why that
> is so as a consequence of digital logic and transistor circuitry
> and electrical signalling.  C/C++ remains a good fit at that level
> because it is still a reflection of the hardware.
> 
> I agree with Steve - and so would Ken as I have heard him say
> it several times going back many years - the kernel is basically
> a multiplexor for memory, io, and time.  What happens above that
> in terms of data representation and anything like intelligence
> is a higher-order function and demands higher-order programming
> than what works for most kernel tasks.  I use the term "higher-order"
> in the same sense that Church's type theory (lambda calculus)
> is higher order than first order predicate logic.
> 
> I've always liked what Knuth wrote long ago about the evolution
> of programming languages.  He observed that languages
> have evolved first from binary, to assembly language, and
> then jumped to Fortran because programmers who found
> they were writing the same kind of stuff over and over,
> sometimes in the same program, looked for ways to express
> more with less.  That still happens today and will continue.
> 
> But wait, there's more.
> Imagine what would be needed to implement a human brain model
> with something like 10^11 neurons and 10^14 connections.
> Out of reach today.
> 
> People are just now trying to emulate the 302 neurons in the nervous
> system of Caenorhabditis elegans. C/C++ and Von Neumann cpus
> are not a good match for such problems - and there are many
> computations (and searches) of stupendous enormous scale that would dwarf
> any supercomputer in the planning stages today.
> 
> I hope I get to see some of what comes next, and maybe even
> help carry forward a few building blocks.
> 
> What started this conversation?
> 
> Greg
> 
> 
> On Tue, Jun 3, 2014 at 6:10 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> > First, let me say how cool it is to be replying to the guy who did yacc.
> > I've used it for decades, thank you for that.
> >
> > I was at SGI when they did the Origin servers, the architecture (as I
> > remember it) was a board with 2 CPUS, some local memory, and an connection
> > to a hypercube style of memory.  An interesting aside is that this is
> > where I learned that infinitely large packets in a network are infinitely
> > stupid because you have to buffer a packet if the outgoing port is busy.
> > I used to be a fan of big packets on ethernet, that system taught me
> > that ethernet is just fine.  The Origin "network" had ~32 byte packets.
> > Buffering those was "easy".
> >
> > The problem with the lots-of-cpus design is that memory latency goes up.
> > It was OK for local memory, it was not OK for remote memory.  Don't get
> > me wrong, SGI did a really great job at it, but when you compare a bunch
> > of networked boxes with the SMP model SGI had, SGI won on jobs that needed
> > shared memory, the bunch of networked boxes kicked ass on everything else.
> > Cross reference: google.  Intel's test harness.  And a bunch of others.
> > When you are benchmarking against a 10,000 node cluster and the cluster
> > is winning, yeah, you need to rethink what you are doing.
> >
> > I've copied Greg Chesson, you guys should know him, he's ex Bell Labs,
> > he can correct my ramblings, I worked for him at SGI.
> >
> > --lm
> >
> > On Tue, Jun 03, 2014 at 11:48:25AM -0700, scj at yaccman.com wrote:
> > > Well, I'm sure my biases are showing, but I see the Kernel as a means for
> > > supplying features for a model of computation, and the programming
> > > language as the delivery vehicle for that model of computation.  And in
> > my
> > > view, C/C++ is far more obsolete than Linux.
> > >
> > > Hardware has left software in the dust.  It is quite feasible to produce
> > a
> > > chip with 1000 or 10,000 processors on it, each with a bit of memory and
> > a
> > > communication fabric.  That's what tomorrow's technology is giving us.
> > > Multicore and named threads are just not going to cut it when using such
> > a
> > > system.  A central supplier of any service is a bottleneck.  We've got to
> > > write our software to act more like an ant farm than a military
> > hierarchy.
> > >
> > > Otherwise said, we have to learn to think different.  Very different.
> >  And
> > > the hardest part of that is letting go of the old ways of thinking.
> > > Perhaps encroaching senility is help in this...
> > >
> > > Steve
> >

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


From arno.griffioen at ieee.org  Thu Jun  5 17:31:12 2014
From: arno.griffioen at ieee.org (Arno Griffioen)
Date: Thu, 5 Jun 2014 09:31:12 +0200
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140602142446.GM18282@mercury.ccil.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <20140602142446.GM18282@mercury.ccil.org>
Message-ID: <20140605073112.GD10373@attic.nerdnet.nl>

On Mon, Jun 02, 2014 at 10:24:48AM -0400, John Cowan wrote:
> Ronald Natalie scripsit:
> 
> > Still with all it's flaws, on the 286 and later UNIX actually did run in
> > protected mode, something it took ages for DOS/Windows (one can argue
> > backwards compatibility with the early processors) or Apple (no excuse
> > here, the early Macs were 68000's which had protection) to pick up upon.
> 
> The original Mac 128K was a 68000 processor, and IIRC memory protection
> didn't arrive until the 68020.

As mentioned by others the 68010 could, with additional external hardware, 
support memory management.

The original 68000 (and 8-bit data bus 68008) did already have the full 32
bit instruction and data support of the complete family, but for MMU use it 
lacked one critical feature in the fact that it did not push enough page-fault
information on the stack to re-start an instruction in case of an (externally 
signalled) page-fault.

So even if you interfaced external MMU logic then a basic 68000 was still in 
trouble when a page fault occurred as it could not 'start over' the 
faulted instruction.

The 68010 added the correct stack frames to be able to restart a faulted
instruction and also added the first small performance enhancement in the 
form of a 'loop mode' where the CPU could basically cache a small loop 
and execute this without incurring addtional memory wait cycles.

As a result the '010 was usually used in various *NIX machines of the
era like some SUN2's and various machines (one-offs or low production)
from other brands.

Eg. I still have a machine in my collection which is from a small local 
production run that utilises an '010 with a custom, but quite rudimentary, 
MMU based on some simple logic chips and it used to run SVR2. Very slowly 
as it had a whopping 1 Mbyte of RAM and the MMU could give you a virtual 
memory size of 4 Mbyte. 

I did port MINIX to it and added memory management/protection support to 
the kernel. Ran a lot faster :)

With the release of the '020 Motorola delivered their own full-blown (but 
still external) MMU in the shape of the MC68851

Many non-UNIX '020 based machines of the era did not have the MC68851 on 
board at all (eg. most Apples from the time) as it was relatively expensive 
and could incur extra memory latency/cycles being an external unit.

With the '030 Motorola finally moved the MMU onto the same die as the CPU 
(reducing the latency and cost) and it became more prevalent on more 
platforms (although the cheaper 68EC030 was available without an MMU and 
used in many machines)

Bringing this back to UNIX, I used to do some local supporting work at CBM for 
the Commodore UNIX'es that were Amiga, and of course M68k based. 

The official Amiga 2000 '020 turboboard (or one of the A2500UX'es like I have 
at home :) ) does have both the MC68851 MMU and the MC68881 FPU and these
were used for a, mostly in-house at CBM, SVR3.2 based UNIX version. 

AmigaDOS of course also ran fine on it, but did not use the MMU.

The later, general release, SVR4 UNIX version was desgined to run on the
'030 based A3000UX'es, although it still ran on the '020+MMU cards in their
limited (4Mb) DRAM.

								Bye, Arno.


From emu at e-bbes.com  Thu Jun  5 18:24:22 2014
From: emu at e-bbes.com (emu at e-bbes.com)
Date: Thu, 05 Jun 2014 10:24:22 +0200
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140605073112.GD10373@attic.nerdnet.nl>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <20140602142446.GM18282@mercury.ccil.org>
 <20140605073112.GD10373@attic.nerdnet.nl>
Message-ID: <20140605102422.gzf106rf5moc88c0@webmail.opentransfer.com>

Zitat von Arno Griffioen <arno.griffioen at ieee.org>:

> As a result the '010 was usually used in various *NIX machines of the
> era like some SUN2's and various machines (one-offs or low production)
> from other brands.

One "nice" machine, which actually ran Unix on the 68010 was:
http://en.wikipedia.org/wiki/AT%26T_Unix_PC



From wes.parish at paradise.net.nz  Thu Jun  5 19:17:04 2014
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Thu, 05 Jun 2014 21:17:04 +1200 (NZST)
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140605073112.GD10373@attic.nerdnet.nl>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <20140602142446.GM18282@mercury.ccil.org>
 <20140605073112.GD10373@attic.nerdnet.nl>
Message-ID: <1401959824.53903590d25f5@www.paradise.net.nz>

Which of course raises the question: how did AmigaDOS manage context switches
and the like for its brand of multitasking? I know BYTE explained it in the
early 1990s, but I threw away all my BYTEs a couple of decades ago, and don't
remember the details.

Thanks

Wesley Parish

Quoting Arno Griffioen <arno.griffioen at ieee.org>:

> On Mon, Jun 02, 2014 at 10:24:48AM -0400, John Cowan wrote:
> > Ronald Natalie scripsit:
> > 
> > > Still with all it's flaws, on the 286 and later UNIX actually did
> run in
> > > protected mode, something it took ages for DOS/Windows (one can
> argue
> > > backwards compatibility with the early processors) or Apple (no
> excuse
> > > here, the early Macs were 68000's which had protection) to pick up
> upon.
> > 
> > The original Mac 128K was a 68000 processor, and IIRC memory
> protection
> > didn't arrive until the 68020.
> 
> As mentioned by others the 68010 could, with additional external
> hardware, 
> support memory management.
> 
> The original 68000 (and 8-bit data bus 68008) did already have the full
> 32
> bit instruction and data support of the complete family, but for MMU use
> it 
> lacked one critical feature in the fact that it did not push enough
> page-fault
> information on the stack to re-start an instruction in case of an
> (externally 
> signalled) page-fault.
> 
> So even if you interfaced external MMU logic then a basic 68000 was
> still in 
> trouble when a page fault occurred as it could not 'start over' the 
> faulted instruction.
> 
> The 68010 added the correct stack frames to be able to restart a
> faulted
> instruction and also added the first small performance enhancement in
> the 
> form of a 'loop mode' where the CPU could basically cache a small loop 
> and execute this without incurring addtional memory wait cycles.
> 
> As a result the '010 was usually used in various *NIX machines of the
> era like some SUN2's and various machines (one-offs or low production)
> from other brands.
> 
> Eg. I still have a machine in my collection which is from a small local
> 
> production run that utilises an '010 with a custom, but quite
> rudimentary, 
> MMU based on some simple logic chips and it used to run SVR2. Very
> slowly 
> as it had a whopping 1 Mbyte of RAM and the MMU could give you a virtual
> 
> memory size of 4 Mbyte. 
> 
> I did port MINIX to it and added memory management/protection support to
> 
> the kernel. Ran a lot faster :)
> 
> With the release of the '020 Motorola delivered their own full-blown
> (but 
> still external) MMU in the shape of the MC68851
> 
> Many non-UNIX '020 based machines of the era did not have the MC68851 on
> 
> board at all (eg. most Apples from the time) as it was relatively
> expensive 
> and could incur extra memory latency/cycles being an external unit.
> 
> With the '030 Motorola finally moved the MMU onto the same die as the
> CPU 
> (reducing the latency and cost) and it became more prevalent on more 
> platforms (although the cheaper 68EC030 was available without an MMU and
> 
> used in many machines)
> 
> Bringing this back to UNIX, I used to do some local supporting work at
> CBM for 
> the Commodore UNIX'es that were Amiga, and of course M68k based. 
> 
> The official Amiga 2000 '020 turboboard (or one of the A2500UX'es like I
> have 
> at home :) ) does have both the MC68851 MMU and the MC68881 FPU and
> these
> were used for a, mostly in-house at CBM, SVR3.2 based UNIX version. 
> 
> AmigaDOS of course also ran fine on it, but did not use the MMU.
> 
> The later, general release, SVR4 UNIX version was desgined to run on
> the
> '030 based A3000UX'es, although it still ran on the '020+MMU cards in
> their
> limited (4Mb) DRAM.
> 
> 								Bye, Arno.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuh s
>  



From brantley at coraid.com  Thu Jun  5 21:26:05 2014
From: brantley at coraid.com (Brantley Coile)
Date: Thu, 5 Jun 2014 11:26:05 +0000
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <1401959824.53903590d25f5@www.paradise.net.nz>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <20140602142446.GM18282@mercury.ccil.org>
 <20140605073112.GD10373@attic.nerdnet.nl>,
 <1401959824.53903590d25f5@www.paradise.net.nz>
Message-ID: <1968586D-53E6-4C90-A844-E975FA6FA5AF@coraid.com>

I ported Unix to the 68000 in the early 1980's and I did what I assume AmigoDOS did; getting a page fault for anything but a stack frame access was fatal to the process.  In other worlds, no paging-in a process.  The problem for paging was handling side effects from auto increment or decrement access modes.  If the faulting instruction used one of those modes, the 68000 didn't provide enough information to do what we did on PDP-11's and simulate the faulted instruction.  Nor could it automatically restart the instruction, which was done in the 68010.  A process had to be loaded completely before being swtch'ed to, just like in 32v.  

This left only the fault resulting from the stack meeting to grow.  To solve for that problem, we solicited help from the compiler.  The function prologue of every function would fetch the farthest used word from the frame pointer.  In most cases this would do nothing.  For a frame that needed more stack allocated, this would cause a page fault.  We looked at the instruction at the faulted program counter, verified it was a "grow me" instruction, allocated more core and put the process back on the run queue.  The result of the instruction was ignored, so we didn't need to have the kernel restart it or simulate it.  

This method wasn't original to me. It was common practice at the time.  I assume this the technique used by AmigaDOS.

Sent from my iPad

> On Jun 5, 2014, at 5:33 AM, "Wesley Parish" <wes.parish at paradise.net.nz> wrote:
> 
> Which of course raises the question: how did AmigaDOS manage context switches
> and the like for its brand of multitasking? I know BYTE explained it in the
> early 1990s, but I threw away all my BYTEs a couple of decades ago, and don't
> remember the details.
> 
> Thanks
> 
> Wesley Parish
> 
> Quoting Arno Griffioen <arno.griffioen at ieee.org>:
> 
>>> On Mon, Jun 02, 2014 at 10:24:48AM -0400, John Cowan wrote:
>>> Ronald Natalie scripsit:
>>> 
>>>> Still with all it's flaws, on the 286 and later UNIX actually did
>> run in
>>>> protected mode, something it took ages for DOS/Windows (one can
>> argue
>>>> backwards compatibility with the early processors) or Apple (no
>> excuse
>>>> here, the early Macs were 68000's which had protection) to pick up
>> upon.
>>> 
>>> The original Mac 128K was a 68000 processor, and IIRC memory
>> protection
>>> didn't arrive until the 68020.
>> 
>> As mentioned by others the 68010 could, with additional external
>> hardware, 
>> support memory management.
>> 
>> The original 68000 (and 8-bit data bus 68008) did already have the full
>> 32
>> bit instruction and data support of the complete family, but for MMU use
>> it 
>> lacked one critical feature in the fact that it did not push enough
>> page-fault
>> information on the stack to re-start an instruction in case of an
>> (externally 
>> signalled) page-fault.
>> 
>> So even if you interfaced external MMU logic then a basic 68000 was
>> still in 
>> trouble when a page fault occurred as it could not 'start over' the 
>> faulted instruction.
>> 
>> The 68010 added the correct stack frames to be able to restart a
>> faulted
>> instruction and also added the first small performance enhancement in
>> the 
>> form of a 'loop mode' where the CPU could basically cache a small loop 
>> and execute this without incurring addtional memory wait cycles.
>> 
>> As a result the '010 was usually used in various *NIX machines of the
>> era like some SUN2's and various machines (one-offs or low production)
>> from other brands.
>> 
>> Eg. I still have a machine in my collection which is from a small local
>> 
>> production run that utilises an '010 with a custom, but quite
>> rudimentary, 
>> MMU based on some simple logic chips and it used to run SVR2. Very
>> slowly 
>> as it had a whopping 1 Mbyte of RAM and the MMU could give you a virtual
>> 
>> memory size of 4 Mbyte. 
>> 
>> I did port MINIX to it and added memory management/protection support to
>> 
>> the kernel. Ran a lot faster :)
>> 
>> With the release of the '020 Motorola delivered their own full-blown
>> (but 
>> still external) MMU in the shape of the MC68851
>> 
>> Many non-UNIX '020 based machines of the era did not have the MC68851 on
>> 
>> board at all (eg. most Apples from the time) as it was relatively
>> expensive 
>> and could incur extra memory latency/cycles being an external unit.
>> 
>> With the '030 Motorola finally moved the MMU onto the same die as the
>> CPU 
>> (reducing the latency and cost) and it became more prevalent on more 
>> platforms (although the cheaper 68EC030 was available without an MMU and
>> 
>> used in many machines)
>> 
>> Bringing this back to UNIX, I used to do some local supporting work at
>> CBM for 
>> the Commodore UNIX'es that were Amiga, and of course M68k based. 
>> 
>> The official Amiga 2000 '020 turboboard (or one of the A2500UX'es like I
>> have 
>> at home :) ) does have both the MC68851 MMU and the MC68881 FPU and
>> these
>> were used for a, mostly in-house at CBM, SVR3.2 based UNIX version. 
>> 
>> AmigaDOS of course also ran fine on it, but did not use the MMU.
>> 
>> The later, general release, SVR4 UNIX version was desgined to run on
>> the
>> '030 based A3000UX'es, although it still ran on the '020+MMU cards in
>> their
>> limited (4Mb) DRAM.
>> 
>>                                Bye, Arno.
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuh s
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From jcea at jcea.es  Thu Jun  5 23:34:31 2014
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 05 Jun 2014 15:34:31 +0200
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <1968586D-53E6-4C90-A844-E975FA6FA5AF@coraid.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <20140602142446.GM18282@mercury.ccil.org>
 <20140605073112.GD10373@attic.nerdnet.nl>,
 <1401959824.53903590d25f5@www.paradise.net.nz>
 <1968586D-53E6-4C90-A844-E975FA6FA5AF@coraid.com>
Message-ID: <539071E7.9040807@jcea.es>

On 05/06/14 13:26, Brantley Coile wrote:
> This method wasn't original to me. It was common practice at the
> time.  I assume this the technique used by AmigaDOS.

I have no direct knowledge of AmigaDOS, but since there was no hardware
protection between processes and all processes shared the same address
space, context switching COULD BE just "store process registers,
including stack pointer and Program Counter, for process A", "restore
process registers, including stack pointer and program counter from
process B".

Certainly I did this in the 8 bit era (well, 6502 CPU have the stack in
a fixed position but only just 256 bytes long, so I just copy it around
when doing context switching) and in Atari ST (68000 based computer).

-- 
Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140605/fc3e0d8a/attachment.sig>

From clemc at ccc.com  Fri Jun  6 01:07:44 2014
From: clemc at ccc.com (Clem Cole)
Date: Thu, 5 Jun 2014 11:07:44 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <20140605073112.GD10373@attic.nerdnet.nl>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <20140602142446.GM18282@mercury.ccil.org>
 <20140605073112.GD10373@attic.nerdnet.nl>
Message-ID: <CAC20D2MrY2zCcDcFm=kOmSR3H98evRQdEei3zxkqjEVfoNO57Q@mail.gmail.com>

On Thu, Jun 5, 2014 at 3:31 AM, Arno Griffioen ‪<arno.griffioen at ieee.org>
wrote:

The original 68000 (and 8-bit data bus 68008) did already have the full 32

bit instruction and data support of the complete family,


But the original 68000 was actually a 16 bit internal architecture -- is
was made with a 16 bit barrel shifter and any 32 bit op took two ticks.
 Yes, they (fortunately) did define the 32 bit data types and many of the
32 bit operations.   There was an argument at the time was it a 16 bit or
32 bit chip and between people implementing compilers - should a C "int" be
16 bits or 32.



Since I had hacked the Ritchie PDP-11 compiler for mine, I used 16 bits,
while the MIT guys used 32 (I think they were hacking on Steve's if my
memory is correct).   The advantage of the later was int == ptr and that
the time V6 and V7 was definitely pointer "dirty" the worst example being
the Bourne shell and how break(2) was implemented.   The advantage of the
former was it was the natural size of the chip internals and so it made it
easier for me to generate "optimal" (well let's just say "better") code
plus that's what's Dennis's compiler "knew."



Jeff Mogul ended up at Stanford around that time.  He and I had a long
argument about it when we first met.   We each we sure the other was wrong
- :-0   Years later when we became colleagues we reminded of the old
argument, I think we agreed that other was "right."   It was a tough choice
and there were good arguments on both sides.



BTW:  I once asked Les about it during our Stellar time.  He said they
thought of it as a 16 bit chip - a PDP-11 like system without running into
the problem that Cal Data did with "cloning" the 11.  Les and team has been
using PDP-11's before they joined Moto. But the reality is that UNIX code
really wanted int==ptr for a long time [as well as:  ptr = 0; *ptr == 0].
 That really was not forced to be fixed until Alpha came on the scene and
people cleaned up there code.









but for MMU use it
​ ​
lacked one critical feature in the fact that it did not push enough
page-fault

information on the stack to re-start an instruction in case of an
(externally
​ ​
signalled) page-fault.


True that the original 68000 lacked the instruction restart ability, but
the MMU could be made to not need restart.





So even if you interfaced external MMU logic then a basic 68000 was still in
​ ​
trouble when a page fault occurred as it could not 'start over' the
​ ​
faulted instruction.


As I said this is not completely true - you just never stopped the
instruction.  The fact is that a 68000 could do VM, but it took a bit of
work a external logic.   Forest Basket wrote a paper on how to do it and it
was actually what both Apollo and Masscomp implemented in this first
products.



The trick was that the 68000 "CPU" could not complete the instruction when
the fault occurred (or as you mentioned - the reason was that bad things
happened was because the microcode did not correctly save the internal
instruction state).   So the "executor" 68000 CPU was sent  wait states by
the MMU -- in effect forcing it to have a very slow memory read.   While it
was waiting for the memory to fill, the fault had to be handled by
something else.  In Masscomp's case (and I believe Apollo also) the "fixer"
was another second 68000 that ran in kernel code that handled the fault and
refilled the MMU's TLB (or if you we schooled by Digital - the "TB").



At the time Dave Cane and Jeff ??? ( the logic designer sat Masscomp -
Jeff's last name now escapes me) had been from the 11/34 and VAX projects
previously.  They were horrified to have to use a second processor just for
memory refills, and spent weeks trying to find a way out but eventually
relented to what the SW guys where telling them.



As I said, when the '010 came out, Masscomp retrofitted the CPU card to
allow the fault to occur and not wait state the CPU.  The RTU kernel
detected the actual chip being used, and when it was running on a ' 010,
would immediately do a task switch on the executor and run some other code,
while the fixer handled the fault. I've forgotten now, but my memory is
that the fixer always ran out of the cache.



BTW: the '010 originally still had VM issues that did not get fixed until
the '020.  The way Moto handled the fault was to dump the state of the
internal microcode to the CPU stack, and when the instruction was
restarted, was to suck the state back into the processor.   The problem was
that as that Moto was updating the microcode in manufacturing not thinking
it was an issues for customers a processor with the step logic stepping
might have different microcode - which was not a problem for 99% of their
customers.





However, Masscomp actually made the first dual processor UNIX box - the
MC-500/DP which was released about 12 months after the MC-500  (they
predated Sequent by about 2-3 years).   A couple of months after we started
shipping the DP, we started to see a strange failure in the field.  The
issues was that a fault would occur on one CPU and the kernel would try to
restart to the instruction on a different processor, and unless both CPU
boards had executor chips from the same manufacturing lot - you had to
restart in the same physical chip that took the fault.   Because the
original RTU DP system was modeled on the Goble Vax, were kernel mode was
on one processor at a time and the original DP had a NUMA memory system
(the 5000 was SMP with UMA memory).   Thus usually, processes tended to get
started on one processor and not migrate to the other, but under they could
migrate.   All the test systems in engineering had matched processors - no
problem.   But when field service started to swap boards, around at
customer sites, bad things started to happen.



We had quite the panic figuring out what it was and then forced field
service to ensure all CPU cards were matched -- what a pain in the tuckus.
  With the 5000 when we went full SMP, we screamed at Moto and got them to
clean up their act so that what was dumped on the stack could be restarted
on any '020 regardless of stepping/microcode etc.



Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140605/d296f057/attachment.html>

From ron at ronnatalie.com  Fri Jun  6 04:26:38 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Thu, 5 Jun 2014 14:26:38 -0400
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <CAC20D2MrY2zCcDcFm=kOmSR3H98evRQdEei3zxkqjEVfoNO57Q@mail.gmail.com>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <20140602142446.GM18282@mercury.ccil.org>
 <20140605073112.GD10373@attic.nerdnet.nl>
 <CAC20D2MrY2zCcDcFm=kOmSR3H98evRQdEei3zxkqjEVfoNO57Q@mail.gmail.com>
Message-ID: <BB339AF5-B9A5-418B-933E-349D196EEED4@ronnatalie.com>


On Jun 5, 2014, at 11:07 AM, Clem Cole <clemc at ccc.com> wrote:

> We had quite the panic figuring out what it was and then forced field service to ensure all CPU cards were matched -- what a pain in the tuckus.   With the 5000 when we went full SMP, we screamed at Moto and got them to clean up their act so that what was dumped on the stack could be restarted on any '020 regardless of stepping/microcode etc.
> 
Sounds like our fun with Intel and their i860 RISC chips.    Every chip stepping had it's own "INTEL PROPRIETARY" errata which had fun things like "A store followed by any number of instructions and then a load from the same location may ...."    I loved the fact that Intel didn't think it was a good idea to tell people what they had to do to make the chips work.   Even when we got the Errata, they were sometimes wrong.     I spent a lot of time when stuck calling my contact at the factory and making discrete inquiries which led to things like:

Intel:   Remember those two NOP instructions we told you to put at the beginning of the ISR?
Me:     Yes, but the errata sheet says that ceased to be necessary after the B2 stepping of the chip.
Intel:   Well put them back and perhaps five or six more.

Of course they weren't as bad as dealing with some aspects of IBM at the time.

Me:   There's a bug in the driver for this card.
IBM:  That's not possible, it's product.

Oh, excuse me....there can't possibly be problems in the released product.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140605/06aa8616/attachment.html>

From xtp at google.com  Wed Jun  4 13:42:56 2014
From: xtp at google.com (Greg Chesson)
Date: Tue, 3 Jun 2014 20:42:56 -0700
Subject: [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6
	'dcheck'))
In-Reply-To: <20140604011011.GF17402@mcvoy.com>
References: <CAC20D2NCJU83yEnxA_FDvTMnhU34mhf+c1fDwrXB5fRXtx3npg@mail.gmail.com>
 <59D01DBF-EF49-45B8-8F80-FA03E644A528@tfeb.org>
 <CAC20D2OpxV611CAuXtkZg_cxJX5o5yCq=PXh72mL_QVk+EGOWQ@mail.gmail.com>
 <20140602144105.GO18282@mercury.ccil.org>
 <E5FC5D10-0C02-4D6F-B8D4-82D83614CEEA@ieee.org>
 <F2DFE79D-B9BC-4192-996A-55346142395F@coraid.com>
 <CAEoi9W7x=gq0=jKENXFAzgdsBaDyymXqTJJv982TYCz0GaK01w@mail.gmail.com>
 <20140602194749.GA2463@behemoth>
 <CAEoi9W7B6-m2Yxupar+LuE_J8kJn5chEOEAfwssQYWCOPiYg1g@mail.gmail.com>
 <57e9892e6ab11d0d12d0cea5bf6e8d6b.squirrel@webmail.yaccman.com>
 <20140604011011.GF17402@mcvoy.com>
Message-ID: <CAMN4JoRuqqTsaqnJZX37ej_3+poQzupk3FegV2Jc=w5wz55iUg@mail.gmail.com>

Hi,

I certainly know scj from Murray Hill.  Not sure who is tubs.

Distributed and parallel hardware has evolved far beyond the ability
of most sw.  Everyone agrees, I think; and, GPUs just make it more so.

On the other hand, cpu architecture remains classic Von Neumann
with registers, alus, and familiar memory hierarchies. Close to the
hardware where instructions are visible, there is not much change.
And I think there are compelling technical reasons on why that
is so as a consequence of digital logic and transistor circuitry
and electrical signalling.  C/C++ remains a good fit at that level
because it is still a reflection of the hardware.

I agree with Steve - and so would Ken as I have heard him say
it several times going back many years - the kernel is basically
a multiplexor for memory, io, and time.  What happens above that
in terms of data representation and anything like intelligence
is a higher-order function and demands higher-order programming
than what works for most kernel tasks.  I use the term "higher-order"
in the same sense that Church's type theory (lambda calculus)
is higher order than first order predicate logic.

I've always liked what Knuth wrote long ago about the evolution
of programming languages.  He observed that languages
have evolved first from binary, to assembly language, and
then jumped to Fortran because programmers who found
they were writing the same kind of stuff over and over,
sometimes in the same program, looked for ways to express
more with less.  That still happens today and will continue.

But wait, there's more.
Imagine what would be needed to implement a human brain model
with something like 10^11 neurons and 10^14 connections.
Out of reach today.

People are just now trying to emulate the 302 neurons in the nervous
system of Caenorhabditis elegans. C/C++ and Von Neumann cpus
are not a good match for such problems - and there are many
computations (and searches) of stupendous enormous scale that would dwarf
any supercomputer in the planning stages today.

I hope I get to see some of what comes next, and maybe even
help carry forward a few building blocks.

What started this conversation?

Greg


On Tue, Jun 3, 2014 at 6:10 PM, Larry McVoy <lm at mcvoy.com> wrote:

> First, let me say how cool it is to be replying to the guy who did yacc.
> I've used it for decades, thank you for that.
>
> I was at SGI when they did the Origin servers, the architecture (as I
> remember it) was a board with 2 CPUS, some local memory, and an connection
> to a hypercube style of memory.  An interesting aside is that this is
> where I learned that infinitely large packets in a network are infinitely
> stupid because you have to buffer a packet if the outgoing port is busy.
> I used to be a fan of big packets on ethernet, that system taught me
> that ethernet is just fine.  The Origin "network" had ~32 byte packets.
> Buffering those was "easy".
>
> The problem with the lots-of-cpus design is that memory latency goes up.
> It was OK for local memory, it was not OK for remote memory.  Don't get
> me wrong, SGI did a really great job at it, but when you compare a bunch
> of networked boxes with the SMP model SGI had, SGI won on jobs that needed
> shared memory, the bunch of networked boxes kicked ass on everything else.
> Cross reference: google.  Intel's test harness.  And a bunch of others.
> When you are benchmarking against a 10,000 node cluster and the cluster
> is winning, yeah, you need to rethink what you are doing.
>
> I've copied Greg Chesson, you guys should know him, he's ex Bell Labs,
> he can correct my ramblings, I worked for him at SGI.
>
> --lm
>
> On Tue, Jun 03, 2014 at 11:48:25AM -0700, scj at yaccman.com wrote:
> > Well, I'm sure my biases are showing, but I see the Kernel as a means for
> > supplying features for a model of computation, and the programming
> > language as the delivery vehicle for that model of computation.  And in
> my
> > view, C/C++ is far more obsolete than Linux.
> >
> > Hardware has left software in the dust.  It is quite feasible to produce
> a
> > chip with 1000 or 10,000 processors on it, each with a bit of memory and
> a
> > communication fabric.  That's what tomorrow's technology is giving us.
> > Multicore and named threads are just not going to cut it when using such
> a
> > system.  A central supplier of any service is a bottleneck.  We've got to
> > write our software to act more like an ant farm than a military
> hierarchy.
> >
> > Otherwise said, we have to learn to think different.  Very different.
>  And
> > the hardest part of that is letting go of the old ways of thinking.
> > Perhaps encroaching senility is help in this...
> >
> > Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140603/4f859092/attachment.html>

From mparson at bl.org  Wed Jun 11 22:10:17 2014
From: mparson at bl.org (Michael Parson)
Date: Wed, 11 Jun 2014 07:10:17 -0500 (CDT)
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <1401959824.53903590d25f5@www.paradise.net.nz>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <20140602142446.GM18282@mercury.ccil.org>
 <20140605073112.GD10373@attic.nerdnet.nl>
 <1401959824.53903590d25f5@www.paradise.net.nz>
Message-ID: <alpine.NEB.2.11.1406110709500.4538@neener.bl.org>

On Thu, 5 Jun 2014, Wesley Parish wrote:

> Which of course raises the question: how did AmigaDOS manage context switches
> and the like for its brand of multitasking? I know BYTE explained it in the
> early 1990s, but I threw away all my BYTEs a couple of decades ago, and don't
> remember the details.

If you want to re-read the original article:

https://archive.org/details/BYTE_Vol_10-08_1985-08_The_Amiga

-- 
Michael Parson
Austin, TX
KF5LGQ


From wes.parish at paradise.net.nz  Thu Jun 12 11:20:39 2014
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Thu, 12 Jun 2014 13:20:39 +1200 (NZST)
Subject: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
In-Reply-To: <alpine.NEB.2.11.1406110709500.4538@neener.bl.org>
References: <201406020209.s5229Q5o006174@stowe.cs.dartmouth.edu>
 <CAC20D2M3KuBcVGgD6rE-u0JLuQQ=J374DFiqK4kBgOdh3xcSwQ@mail.gmail.com>
 <FBA977D9-C128-4321-8671-2799EAF06715@ronnatalie.com>
 <20140602142446.GM18282@mercury.ccil.org>
 <20140605073112.GD10373@attic.nerdnet.nl>
 <1401959824.53903590d25f5@www.paradise.net.nz>
 <alpine.NEB.2.11.1406110709500.4538@neener.bl.org>
Message-ID: <1402536039.5399006719ff4@www.paradise.net.nz>

Thanks. Will do.

Quoting Michael Parson <mparson at bl.org>:

> On Thu, 5 Jun 2014, Wesley Parish wrote:
> 
> > Which of course raises the question: how did AmigaDOS manage context
> switches
> > and the like for its brand of multitasking? I know BYTE explained it
> in the
> > early 1990s, but I threw away all my BYTEs a couple of decades ago,
> and don't
> > remember the details.
> 
> If you want to re-read the original article:
> 
> https://archive.org/details/BYTE_Vol_10-08_1985-08_The_Amiga 
> 
> -- 
> Michael Parson
> Austin, TX
> KF5LGQ
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuh s
>  




From slapinid at gmail.com  Thu Jun 12 13:10:16 2014
From: slapinid at gmail.com (Sergey Lapin)
Date: Thu, 12 Jun 2014 07:10:16 +0400
Subject: [TUHS] UNIX magazines
Message-ID: <CAFZPMoZC5gPjXKJ6_N_xeJxt=hb2hfXvqi_PWvm07ydwPok9ww@mail.gmail.com>

Hi, all!

I've read recently published link to byte article and got an idea....
Was there a magazine related to UNIX systems in 70s-80s?
I had so much fun reading that Byte issue, even ads (especially ads!)
It is so fun...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140612/decaa92b/attachment.html>

From dscherrer at solar.stanford.edu  Thu Jun 12 13:38:42 2014
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Wed, 11 Jun 2014 20:38:42 -0700
Subject: [TUHS] UNIX magazines
In-Reply-To: <CAFZPMoZC5gPjXKJ6_N_xeJxt=hb2hfXvqi_PWvm07ydwPok9ww@mail.gmail.com>
References: <CAFZPMoZC5gPjXKJ6_N_xeJxt=hb2hfXvqi_PWvm07ydwPok9ww@mail.gmail.com>
Message-ID: <539920C2.8050409@solar.stanford.edu>

Oh yes, there was Unix Review, and several others.  Unix Review was 
special in that
the editor chose to set up an Editorial Board by inviting key people in 
the Unix
field, e.g. John Mashey, Steve Bourne, etc., to direct and comment upon 
editorial content (in
a volunteer, as opposed to paid, fashion). The group met once a month at 
Chantilly,
a posh restaurant in Palo Alto.

Deborah


On 6/11/14 8:10 PM, Sergey Lapin wrote:
> Hi, all!
>
> I've read recently published link to byte article and got an idea....
> Was there a magazine related to UNIX systems in 70s-80s?
> I had so much fun reading that Byte issue, even ads (especially ads!)
> It is so fun...
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140611/4b329671/attachment.html>

From downing.nick at gmail.com  Thu Jun 12 13:46:56 2014
From: downing.nick at gmail.com (Nick Downing)
Date: Thu, 12 Jun 2014 13:46:56 +1000
Subject: [TUHS] UNIX magazines
In-Reply-To: <CAFZPMoZC5gPjXKJ6_N_xeJxt=hb2hfXvqi_PWvm07ydwPok9ww@mail.gmail.com>
References: <CAFZPMoZC5gPjXKJ6_N_xeJxt=hb2hfXvqi_PWvm07ydwPok9ww@mail.gmail.com>
Message-ID: <CAH1jEzb1yHd8v3PRCWAUHuVCcRE8ts7FnCzusUC3xxusjGsobw@mail.gmail.com>

hehe my thoughts too..like a time machine :)
On 12/06/2014 1:11 PM, "Sergey Lapin" <slapinid at gmail.com> wrote:

> Hi, all!
>
> I've read recently published link to byte article and got an idea....
> Was there a magazine related to UNIX systems in 70s-80s?
> I had so much fun reading that Byte issue, even ads (especially ads!)
> It is so fun...
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140612/77283178/attachment.html>

From crossd at gmail.com  Thu Jun 12 13:59:04 2014
From: crossd at gmail.com (Dan Cross)
Date: Wed, 11 Jun 2014 23:59:04 -0400
Subject: [TUHS] UNIX magazines
In-Reply-To: <CAFZPMoZC5gPjXKJ6_N_xeJxt=hb2hfXvqi_PWvm07ydwPok9ww@mail.gmail.com>
References: <CAFZPMoZC5gPjXKJ6_N_xeJxt=hb2hfXvqi_PWvm07ydwPok9ww@mail.gmail.com>
Message-ID: <CAEoi9W67NX4Yc-mLsEj=sDLncoBxayaK5+ayHn94mnnGyXTV+Q@mail.gmail.com>

There were several, starting I guess in the 80s mostly.  The one I remember
in particular was "Unix Review", but there were a few "journal" type
magazines that also specialized in Unix-y things (e.g., ";login:" from
USENIX; still published, I believe), and several associated with particular
vendors: "SunExpert" was one, if I recall correctly.

Occasionally, Unix and related things showed up in the "mainstream"
consumer computer press of the time.  I can remember in particular an issue
of "PC Magazine" (I think June of 1993) that ran a lengthy couple of
articles proving machines from Sun and SGI, in addition to version of Unix
that ran on PCs (interestingly, Linux was omitted despite really starting
to capture a lot of the imagination in that space; similarly I don't recall
any mention of BSD).

Some of these old magazines are definitely blasts from the past.

        - Dan C.



On Wed, Jun 11, 2014 at 11:10 PM, Sergey Lapin <slapinid at gmail.com> wrote:

> Hi, all!
>
> I've read recently published link to byte article and got an idea....
> Was there a magazine related to UNIX systems in 70s-80s?
> I had so much fun reading that Byte issue, even ads (especially ads!)
> It is so fun...
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140611/1a043786/attachment.html>

From jaapna at xs4all.nl  Thu Jun 12 18:00:27 2014
From: jaapna at xs4all.nl (Jaap Akkerhuis)
Date: Thu, 12 Jun 2014 10:00:27 +0200
Subject: [TUHS] UNIX magazines
In-Reply-To: <539920C2.8050409@solar.stanford.edu>
References: <CAFZPMoZC5gPjXKJ6_N_xeJxt=hb2hfXvqi_PWvm07ydwPok9ww@mail.gmail.com>
 <539920C2.8050409@solar.stanford.edu>
Message-ID: <54CA3DB9-C496-490E-A72C-CCE2CD82F3AD@xs4all.nl>


On Jun 12, 2014, at 5:38, Deborah Scherrer <dscherrer at solar.stanford.edu> wrote:

> The group met once a month at Chantilly,
> a posh restaurant in Palo Alto. 

Reminds me of a story (might have been an urban legend) that someone
was making money out of these diners.  He new when they where and
in exchange for money he would introduce people to the celebrities.

	jaap
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140612/a3a1f624/attachment.sig>

From dscherrer at solar.stanford.edu  Fri Jun 13 02:07:45 2014
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Thu, 12 Jun 2014 09:07:45 -0700
Subject: [TUHS] UNIX magazines
In-Reply-To: <54CA3DB9-C496-490E-A72C-CCE2CD82F3AD@xs4all.nl>
References: <CAFZPMoZC5gPjXKJ6_N_xeJxt=hb2hfXvqi_PWvm07ydwPok9ww@mail.gmail.com>
 <539920C2.8050409@solar.stanford.edu>
 <54CA3DB9-C496-490E-A72C-CCE2CD82F3AD@xs4all.nl>
Message-ID: <5399D051.3050708@solar.stanford.edu>

Nope.   I was on those Boards.  That didn't happen.

Debbie

On 6/12/14 1:00 AM, Jaap Akkerhuis wrote:
> On Jun 12, 2014, at 5:38, Deborah Scherrer <dscherrer at solar.stanford.edu> wrote:
>
>> The group met once a month at Chantilly,
>> a posh restaurant in Palo Alto.
> Reminds me of a story (might have been an urban legend) that someone
> was making money out of these diners.  He new when they where and
> in exchange for money he would introduce people to the celebrities.
>
> 	jaap



From jhj at trnsz.com  Thu Jun 12 22:56:46 2014
From: jhj at trnsz.com (Jeff Johnson)
Date: Thu, 12 Jun 2014 08:56:46 -0400
Subject: [TUHS] UNIX magazines
In-Reply-To: <CAEoi9W67NX4Yc-mLsEj=sDLncoBxayaK5+ayHn94mnnGyXTV+Q@mail.gmail.com>
References: <CAFZPMoZC5gPjXKJ6_N_xeJxt=hb2hfXvqi_PWvm07ydwPok9ww@mail.gmail.com>
 <CAEoi9W67NX4Yc-mLsEj=sDLncoBxayaK5+ayHn94mnnGyXTV+Q@mail.gmail.com>
Message-ID: <475C9682-637A-40F0-9E87-692185D3A42B@trnsz.com>

There is also SGI's Iris Universe, which was their in-house magazine. I have no idea when it started or ceased but I have quite a few of the early and mid 1990s issues that have really great articles and advertisements. 

I'll have to see if I can find them and scan them in to share.

--
Jeff Johnson
jhj at trnsz.com

> On Jun 11, 2014, at 11:59 PM, Dan Cross <crossd at gmail.com> wrote:
> 
> There were several, starting I guess in the 80s mostly.  The one I remember in particular was "Unix Review", but there were a few "journal" type magazines that also specialized in Unix-y things (e.g., ";login:" from USENIX; still published, I believe), and several associated with particular vendors: "SunExpert" was one, if I recall correctly.
> 
> Occasionally, Unix and related things showed up in the "mainstream" consumer computer press of the time.  I can remember in particular an issue of "PC Magazine" (I think June of 1993) that ran a lengthy couple of articles proving machines from Sun and SGI, in addition to version of Unix that ran on PCs (interestingly, Linux was omitted despite really starting to capture a lot of the imagination in that space; similarly I don't recall any mention of BSD).
> 
> Some of these old magazines are definitely blasts from the past.
> 
>         - Dan C.
> 
> 
> 
>> On Wed, Jun 11, 2014 at 11:10 PM, Sergey Lapin <slapinid at gmail.com> wrote:
>> Hi, all!
>> 
>> I've read recently published link to byte article and got an idea....
>> Was there a magazine related to UNIX systems in 70s-80s?
>> I had so much fun reading that Byte issue, even ads (especially ads!)
>> It is so fun...
>> 
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140612/1bf3c8e9/attachment.html>

From norman at oclsc.org  Fri Jun 13 10:45:44 2014
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 12 Jun 2014 20:45:44 -0400 (EDT)
Subject: [TUHS] UNIX magazines
Message-ID: <20140613004544.E9DFD1DE37F@lignose.oclsc.org>

Dan Cross:

  ... there were a few "journal" type
  magazines that also specialized in Unix-y things (e.g., ";login:" from
  USENIX; still published, I believe) ...

======

;login: is alive and well.  So is USENIX.  It's no longer
the UNIX user's group it started as many decades ago; the
focus has broadened to advanced computing and systems
research, though the descendants of UNIX are still prominent
in those areas.

For an old-fashioned programmer/systems hack/systems generalist
like me, it's still quite a worthwhile journal and a worthwhile
organization.  They've even been known to have a talk or two
about resurrecting old versions of UNIX.

I'm just off to the federation of medium-sized conferences
and workshops that has grown out of the former USENIX
Annual Technical Conference.  I'm looking forward to it.

Norman Wilson
Toronto ON


From doug at cs.dartmouth.edu  Fri Jun 13 12:18:31 2014
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 12 Jun 2014 22:18:31 -0400
Subject: [TUHS] UNIX magazines
Message-ID: <201406130218.s5D2IVS9022877@stowe.cs.dartmouth.edu>

> ;login: is alive and well. 

For a few years Usenix even published a refereed technical
journal, "Computing Systems", quite different in tone from
;login:  It had some nice content. Does anyone know why
it folded?

Doug


From arnold at skeeve.com  Fri Jun 13 12:45:13 2014
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 12 Jun 2014 20:45:13 -0600
Subject: [TUHS] UNIX magazines
In-Reply-To: <201406130218.s5D2IVS9022877@stowe.cs.dartmouth.edu>
References: <201406130218.s5D2IVS9022877@stowe.cs.dartmouth.edu>
Message-ID: <201406130245.s5D2jDOu014594@freefriends.org>

Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> > ;login: is alive and well. 
>
> For a few years Usenix even published a refereed technical
> journal, "Computing Systems", quite different in tone from
> ;login:  It had some nice content.

I have the full set on a shelf in my basement.

> Does anyone know why it folded?

ISTR that they simply ran out of content; they weren't getting
enough submissions to keep it going, and journal production isn't
an inexpensive undertaking.

Arnold


From norman at oclsc.org  Fri Jun 13 14:03:22 2014
From: norman at oclsc.org (Norman Wilson)
Date: Fri, 13 Jun 2014 00:03:22 -0400 (EDT)
Subject: [TUHS] UNIX magazines
Message-ID: <20140613040322.793E81DE37F@lignose.oclsc.org>

Doug McIlroy:

> Does anyone know why [Computing Systems] folded?

Arnold Skeeve:

  ISTR that they simply ran out of content; they weren't getting
  enough submissions to keep it going, and journal production isn't
  an inexpensive undertaking.

======

That's what I remember too, though there may also have been
insufficient interest from the members.  The front matter
in the last issue suggests that.

Computing Systems was published from Winter 1988 to Fall 1996.
(More years than I'd have guessed, even looking at the physical
journals on my shelf; it was a quarterly.)  It would probably
not have lasted much longer no matter what, as the USENIX
community was likely in the forefront of putting papers online
on the World-Wide Web.

USENIX now makes all their conference papers available online,
free to anyone, except that only those registered for a
conference can read them before the conference actually happens.
That's not a bad substitute for a journal, I suppose.

Norman Wilson
Toronto ON


From arnold at skeeve.com  Fri Jun 13 14:54:50 2014
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 12 Jun 2014 22:54:50 -0600
Subject: [TUHS] UNIX magazines
In-Reply-To: <20140613040322.793E81DE37F@lignose.oclsc.org>
References: <20140613040322.793E81DE37F@lignose.oclsc.org>
Message-ID: <201406130454.s5D4socW025618@freefriends.org>

norman at oclsc.org (Norman Wilson) wrote:

> Arnold Skeeve:

'skeeve' is my domain name. Robbins is my surname.


From tuhs at cuzuco.com  Fri Jun 13 15:07:01 2014
From: tuhs at cuzuco.com (Brian Walden)
Date: Fri, 13 Jun 2014 01:07:01 -0400 (EDT)
Subject: [TUHS] UNIX magazines
Message-ID: <201406130507.s5D571jv022914@cuzuco.com>

UNIX/WORLD started in 1984 and was renamed UnixWorld Magazine: Open
Systems Computing in 1991 and then UnixWorld's Open Computing in 1994
and it folded in 1995.

SunExpert started in 1989 was renamed to Server/Workstatsion Expert in
1999 and it folded in 2001.  I always enjoyed Mike OBrien's offbeat
"Ask Mr. Protocol"

> From: Dan Cross <crossd at gmail.com>
> There were several, starting I guess in the 80s mostly.  The one I remember
> in particular was "Unix Review", but there were a few "journal" type
> magazines that also specialized in Unix-y things (e.g., ";login:" from
> USENIX; still published, I believe), and several associated with particular
> vendors: "SunExpert" was one, if I recall correctly.
> 
> Occasionally, Unix and related things showed up in the "mainstream"
> consumer computer press of the time.  I can remember in particular an issue
> of "PC Magazine" (I think June of 1993) that ran a lengthy couple of
> articles proving machines from Sun and SGI, in addition to version of Unix
> that ran on PCs (interestingly, Linux was omitted despite really starting
> to capture a lot of the imagination in that space; similarly I don't recall
> any mention of BSD).
> 
> Some of these old magazines are definitely blasts from the past.
> 
>         - Dan C.
> 
> 
> 
> On Wed, Jun 11, 2014 at 11:10 PM, Sergey Lapin <slapinid at gmail.com> wrote:
> 
> > Hi, all!
> >
> > I've read recently published link to byte article and got an idea....
> > Was there a magazine related to UNIX systems in 70s-80s?
> > I had so much fun reading that Byte issue, even ads (especially ads!)
> > It is so fun...
> >
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> >


From norman at oclsc.org  Fri Jun 13 22:03:21 2014
From: norman at oclsc.org (Norman Wilson)
Date: Fri, 13 Jun 2014 08:03:21 -0400 (EDT)
Subject: [TUHS] UNIX magazines
Message-ID: <20140613120321.A51F71DE376@lignose.oclsc.org>

  'skeeve' is my domain name. Robbins is my surname.

Sorry about that; up too late with too many balls
in the air (packing, finishing a tax return, listening
to our provincial election results).

At least I didn't further truncate it to skeev, as
Ken might have done.


From arnold at skeeve.com  Fri Jun 13 23:10:08 2014
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 13 Jun 2014 07:10:08 -0600
Subject: [TUHS] UNIX magazines
In-Reply-To: <20140613120321.A51F71DE376@lignose.oclsc.org>
References: <20140613120321.A51F71DE376@lignose.oclsc.org>
Message-ID: <201406131310.s5DDA8H2021287@freefriends.org>

norman at oclsc.org (Norman Wilson) wrote:

>   'skeeve' is my domain name. Robbins is my surname.
>
> Sorry about that; up too late with too many balls
> in the air (packing, finishing a tax return, listening
> to our provincial election results).

NP.

> At least I didn't further truncate it to skeev, as
> Ken might have done.

:-)

Arnold


From clemc at ccc.com  Fri Jun 13 23:43:18 2014
From: clemc at ccc.com (Clem Cole)
Date: Fri, 13 Jun 2014 09:43:18 -0400
Subject: [TUHS] UNIX magazines
In-Reply-To: <20140613040322.793E81DE37F@lignose.oclsc.org>
References: <20140613040322.793E81DE37F@lignose.oclsc.org>
Message-ID: <CAC20D2NUFCJwoRU=pozb=mR8z2TGCs87aTn0NPn=FXCpkWQuUA@mail.gmail.com>

On Fri, Jun 13, 2014 at 12:03 AM, Norman Wilson <norman at oclsc.org> wrote:

> USENIX now makes all their conference papers available online,
> free to anyone, except that only those registered for a
> conference can read them before the conference actually happens.
> That's not a bad substitute for a journal, I suppose.
>

​Thank you Norman.​

​As President of USENIX during that choice, that is a legacy I am
particularly proud.  It was a bit of a scary thing to do and so far ACM and
IEEE have been loath to follow suite as completely (I suspect because the
digital library is (was) a significant source of revenue for all three
organizations).  [To be fair, there are some exceptions, I believe ACM
Queue is downloadable - although I note that it is interesting a lot of
people working on Queue are also USENIX folks some of whom may be lurking
on this mailing list].

For what ever its worth, just a month or so ago, I was very pleased to see
my now Sr in college CS major daughter  -- who went to her first USENIX
conference in 1993 in stroller -- just joined USENIX (maybe its a little
like joining "the party").  But if USENIX is to continue their tradition of
being open and freely accessible, I offer an unabashed advertisement (i.e
no pay walls): like her and her college peers, please consider a USENIX
membership and/or going to a conference or two.


To Doug's question -- I agree that the answers about "Computing Systems"
that have been given are pretty much to the mark.   It was not an
insignificant undertaking to publish such a journal; and keeping
it/dropping was a trade off.

To all on the list, I can say that the Board has toyed with bring it back a
couple of times when I was on it.   If any of you have thoughts on the
matter, send them to the current Board of Directors ( bod at usenix.org )
and/or the Executive Director:  Casey Henderson (execdir at usenix.org).


Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140613/72408362/attachment.html>

From scj at yaccman.com  Sat Jun 14 02:04:35 2014
From: scj at yaccman.com (scj at yaccman.com)
Date: Fri, 13 Jun 2014 09:04:35 -0700
Subject: [TUHS] UNIX magazines
In-Reply-To: <CAC20D2NUFCJwoRU=pozb=mR8z2TGCs87aTn0NPn=FXCpkWQuUA@mail.gmail.com>
References: <20140613040322.793E81DE37F@lignose.oclsc.org>
 <CAC20D2NUFCJwoRU=pozb=mR8z2TGCs87aTn0NPn=FXCpkWQuUA@mail.gmail.com>
Message-ID: <e74d9823ba43e2c02c3e9fb40434536d.squirrel@webmail.yaccman.com>

I was on the Usenix board when we decided to stop publishing Computing
Systems.  One of the key problems, not yet mentioned, was that the
readership was too small.  Several very good papers went elsewhere because
the authors correctly felt that few people would see them if they
published in CS.  A related problem was that many university libraries
were reluctant to subscribe.  It seems that a certain critical mass is
necessary to make a journal viable, and we never quite got there with
CS...


> On Fri, Jun 13, 2014 at 12:03 AM, Norman Wilson <norman at oclsc.org> wrote:
>
>> USENIX now makes all their conference papers available online,
>> free to anyone, except that only those registered for a
>> conference can read them before the conference actually happens.
>> That's not a bad substitute for a journal, I suppose.
>>
>
> âThank you Norman.â
>
> âAs President of USENIX during that choice, that is a legacy I am
> particularly proud.  It was a bit of a scary thing to do and so far ACM
> and
> IEEE have been loath to follow suite as completely (I suspect because the
> digital library is (was) a significant source of revenue for all three
> organizations).  [To be fair, there are some exceptions, I believe ACM
> Queue is downloadable - although I note that it is interesting a lot of
> people working on Queue are also USENIX folks some of whom may be lurking
> on this mailing list].
>
> For what ever its worth, just a month or so ago, I was very pleased to see
> my now Sr in college CS major daughter  -- who went to her first USENIX
> conference in 1993 in stroller -- just joined USENIX (maybe its a little
> like joining "the party").  But if USENIX is to continue their tradition
> of
> being open and freely accessible, I offer an unabashed advertisement (i.e
> no pay walls): like her and her college peers, please consider a USENIX
> membership and/or going to a conference or two.
>
>
> To Doug's question -- I agree that the answers about "Computing Systems"
> that have been given are pretty much to the mark.   It was not an
> insignificant undertaking to publish such a journal; and keeping
> it/dropping was a trade off.
>
> To all on the list, I can say that the Board has toyed with bring it back
> a
> couple of times when I was on it.   If any of you have thoughts on the
> matter, send them to the current Board of Directors ( bod at usenix.org )
> and/or the Executive Director:  Casey Henderson (execdir at usenix.org).
>
>
> Clem
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>




From jgsinowitz at yahoo.com  Sat Jun 14 03:02:33 2014
From: jgsinowitz at yahoo.com (jgsinowitz at yahoo.com)
Date: Fri, 13 Jun 2014 10:02:33 -0700 (PDT)
Subject: [TUHS] TUHS Digest, Vol 113, Issue 21
In-Reply-To: <mailman.494.1402675480.2615.tuhs@minnie.tuhs.org>
Message-ID: <1402678953.55516.YahooMailAndroidMobile@web141601.mail.bf1.yahoo.com>

This is a very enjoyable thread to follow!

Jonah G Sinowitz
Consultant
320 8th Street, #19
Lakewood, NJ 08701
732.367.7450

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140613/497eeff6/attachment.html>

From beebe at math.utah.edu  Sat Jun 14 10:42:59 2014
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Fri, 13 Jun 2014 18:42:59 -0600 (MDT)
Subject: [TUHS] UNIX magazines
Message-ID: <CMM.0.95.0.1402706579.beebe@psi.math.utah.edu>

There is a complete bibliography of the journal Computing Systems
(1988--1996) here:

	http://www.math.utah.edu/pub/tex/bib/compsys.bib
	[change .bib to .html for a version with hyperlinks]

Other journals about aspects of Unix include:

	Bell System Technical journal family (complete 1920--date)
		http://www.math.utah.edu/pub/tex/bib/bstj1920.bib
		http://www.math.utah.edu/pub/tex/bib/bstj1930.bib
		http://www.math.utah.edu/pub/tex/bib/bstj1940.bib
		http://www.math.utah.edu/pub/tex/bib/bstj1950.bib
		http://www.math.utah.edu/pub/tex/bib/bstj1960.bib
		http://www.math.utah.edu/pub/tex/bib/bstj1970.bib
		http://www.math.utah.edu/pub/tex/bib/bstj1980.bib
		http://www.math.utah.edu/pub/tex/bib/bstj1990.bib
		http://www.math.utah.edu/pub/tex/bib/bstj2000.bib
		http://www.math.utah.edu/pub/tex/bib/bstj2010.bib

	Journal of C Language Translation (1989--1995)
		http://www.math.utah.edu/pub/tex/bib/jclt.bib

	Usenix conference proceedings and ";login" journal (incomplete)
		http://www.math.utah.edu/pub/tex/bib/usenix1980.bib
		http://www.math.utah.edu/pub/tex/bib/usenix1990.bib
		http://www.math.utah.edu/pub/tex/bib/usenix2000.bib
		http://www.math.utah.edu/pub/tex/bib/usenix2010.bib

	The X Resource: A Practical Journal of the X Window System (1991--1994)
		http://www.math.utah.edu/pub/tex/bib/xres.bib

There are also bibliographies of books about Unix, Linux, and the GNU
Project:

	http://www.math.utah.edu/pub/tex/bib/gnu.bib
	http://www.math.utah.edu/pub/tex/bib/linux.bib
	http://www.math.utah.edu/pub/tex/bib/unix.bib

Finally, there is a small bibliography of the AT&/Princeton lcc
compiler:

	http://www.math.utah.edu/pub/tex/bib/lcc.bib

There are more than 800 bibliographies in those archives with about
1.01 million entries.  Please mirror them to your site(s): mirror
instructions, overviews, and space requirements can be found at the
top-level sites

	http://www.math.utah.edu/pub/tex/bib/
	http://www.math.utah.edu/pub/bibnet/

The collections are active, and continuously enhanced and extended,
with dozens of files being updated or added weekly.  Using rsync for
mirroring is easy and fast, so nightly or weekly mirrors pose no
problem at either end of the connection.

There is also a TUHS mirror in Salt Lake City, Utah:

	http://www.math.utah.edu/pub/mirrors/minnie.tuhs.org/

It too can be mirrored with rsync.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From a.phillip.garcia at gmail.com  Sat Jun 14 10:53:49 2014
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Fri, 13 Jun 2014 19:53:49 -0500
Subject: [TUHS] UNIX magazines
In-Reply-To: <CMM.0.95.0.1402706579.beebe@psi.math.utah.edu>
References: <CMM.0.95.0.1402706579.beebe@psi.math.utah.edu>
Message-ID: <CAFCBnZs+cK2f1hd8R_W3SUaqvoXS7vo8J6Z-GE+SNtUnutcYfw@mail.gmail.com>

On Jun 13, 2014 7:43 PM, "Nelson H. F. Beebe" <beebe at math.utah.edu> wrote:
>
> There is a complete bibliography of the journal Computing Systems
> (1988--1996) here:
>
>         http://www.math.utah.edu/pub/tex/bib/compsys.bib
>         [change .bib to .html for a version with hyperlinks]
>
> Other journals about aspects of Unix include:
>
>         Bell System Technical journal family (complete 1920--date)
>                 http://www.math.utah.edu/pub/tex/bib/bstj1920.bib
>                 http://www.math.utah.edu/pub/tex/bib/bstj1930.bib
>                 http://www.math.utah.edu/pub/tex/bib/bstj1940.bib
>                 http://www.math.utah.edu/pub/tex/bib/bstj1950.bib
>                 http://www.math.utah.edu/pub/tex/bib/bstj1960.bib
>                 http://www.math.utah.edu/pub/tex/bib/bstj1970.bib
>                 http://www.math.utah.edu/pub/tex/bib/bstj1980.bib
>                 http://www.math.utah.edu/pub/tex/bib/bstj1990.bib
>                 http://www.math.utah.edu/pub/tex/bib/bstj2000.bib
>                 http://www.math.utah.edu/pub/tex/bib/bstj2010.bib
>
>         Journal of C Language Translation (1989--1995)
>                 http://www.math.utah.edu/pub/tex/bib/jclt.bib
>
>         Usenix conference proceedings and ";login" journal (incomplete)
>                 http://www.math.utah.edu/pub/tex/bib/usenix1980.bib
>                 http://www.math.utah.edu/pub/tex/bib/usenix1990.bib
>                 http://www.math.utah.edu/pub/tex/bib/usenix2000.bib
>                 http://www.math.utah.edu/pub/tex/bib/usenix2010.bib
>
>         The X Resource: A Practical Journal of the X Window System
(1991--1994)
>                 http://www.math.utah.edu/pub/tex/bib/xres.bib
>
> There are also bibliographies of books about Unix, Linux, and the GNU
> Project:
>
>         http://www.math.utah.edu/pub/tex/bib/gnu.bib
>         http://www.math.utah.edu/pub/tex/bib/linux.bib
>         http://www.math.utah.edu/pub/tex/bib/unix.bib
>
> Finally, there is a small bibliography of the AT&/Princeton lcc
> compiler:
>
>         http://www.math.utah.edu/pub/tex/bib/lcc.bib
>
> There are more than 800 bibliographies in those archives with about
> 1.01 million entries.  Please mirror them to your site(s): mirror
> instructions, overviews, and space requirements can be found at the
> top-level sites
>
>         http://www.math.utah.edu/pub/tex/bib/
>         http://www.math.utah.edu/pub/bibnet/
>
> The collections are active, and continuously enhanced and extended,
> with dozens of files being updated or added weekly.  Using rsync for
> mirroring is easy and fast, so nightly or weekly mirrors pose no
> problem at either end of the connection.
>
> There is also a TUHS mirror in Salt Lake City, Utah:
>
>         http://www.math.utah.edu/pub/mirrors/minnie.tuhs.org/
>
> It too can be mirrored with rsync.
>
>
-------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
     -
> - University of Utah                    FAX: +1 801 581 4148
     -
> - Department of Mathematics, 110 LCB    Internet e-mail:
beebe at math.utah.edu  -
> - 155 S 1400 E RM 233                       beebe at acm.org
beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL:
http://www.math.utah.edu/~beebe/ -
>
-------------------------------------------------------------------------------

...and those are just the ones that have been baptized. i'm sorry, bad
joke. this is a really nice resource. thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140613/58e9e54b/attachment.html>

From wkt at tuhs.org  Sat Jun 14 13:30:19 2014
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 14 Jun 2014 13:30:19 +1000
Subject: [TUHS] Archive of old ;login or EUUG newsletters?
Message-ID: <20140614033019.GA16666@www.oztivo.net>

Speaking of old publications, is there an on-line archive of old ;login:
or EUUG newsletters? I did one for the AUUG newsletters here:

http://minnie.tuhs.org/Archive/Documentation/AUUGN/

but it would be nice to have an archive for the U.S and Europe.

Cheers,
	Warren


From khm at sciops.net  Sat Jun 14 13:43:52 2014
From: khm at sciops.net (Kurt H Maier)
Date: Sat, 14 Jun 2014 03:43:52 +0000
Subject: [TUHS] Archive of old ;login or EUUG newsletters?
In-Reply-To: <20140614033019.GA16666@www.oztivo.net>
References: <20140614033019.GA16666@www.oztivo.net>
Message-ID: <20140614034352.Horde.O0_m56-ajjnVuE7_2IDHrw4@ssl.eumx.net>

Quoting Warren Toomey <wkt at tuhs.org>:

> Speaking of old publications, is there an on-line archive of old ;login:
> or EUUG newsletters? I did one for the AUUG newsletters here:
>
> http://minnie.tuhs.org/Archive/Documentation/AUUGN/
>
> but it would be nice to have an archive for the U.S and Europe.

https://www.usenix.org/publications/login goes back to 1997, but it's all
webbed up and not suitable for archival.  Between its increasing focus on
web nonsense and the inexplicable canning of SAGE, I dropped my USENIX
membership a while back.  This thread has served to make me look closely
as to whether I am getting any actual value out of my ACM membership.

khm



From dds at aueb.gr  Mon Jun 16 00:46:44 2014
From: dds at aueb.gr (Diomidis Spinellis)
Date: Sun, 15 Jun 2014 17:46:44 +0300
Subject: [TUHS] Tree of late BSD releases
Message-ID: <539DB1D4.3080909@aueb.gr>

For reconstructing Unix history on a single repository [1], I'd need to 
represent the branches, merges, and chronological sequence of the late 
BSD releases (after 4.3).  However, I've found on the internet some 
conflicting and simplistic information, so I'd welcome your input on how 
to straighten things up.

First, consider this widely reproduced BSD family tree [2].  It has 
4.4BSD-Encumbered derive from a line that includes Net/1, which was 
freely redistributable.  Wouldn't it be clearer to create two branches, 
one with distributions free of AT&T code (4.3 BSD Net/1, 4.3 BSD Net/2, 
4.4 BSD Lite1, 4.4 BSD Lite2) and one with full distributions (4.4 BSD, 
...)?  On which side would Tahoe and Reno stand?

Also, the same tree [2] shows 4.4 BSD having as its ancestor 4.3 BSD 
Net/2, whereas another tree depicted on Wikipedia [3] has shows 4.4 BSD 
and 4.3 BSD Net/2 having as their ancestor 4.3 BSD Reno.  What's the 
correct genealogy?

Finally, I have a conflict with release dates.  Wikipedia gives the 
following dates for Tahoe and Net/1 [4]:

4.3 BSD Tahoe June 1988
4.3 BSD Net/1 June 1989

However, looking at time-stamp of the newest files available under the 
corresponding directories in the CSRG CD-ROMs [5] I find the opposite order:

cd2/net.1/sendmail/src/util.c 1989-01-01 12:15:58
cd2/4.3tahoe/usr/src/sys/tahoevba/vx.c 1989-05-23 13:47:43

What's the actual time sequence, and what's the corresponding genealogy?

[1] https://github.com/dspinellis/unix-history-repo
[2] 
http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/share/misc/bsd-family-tree
[3] https://en.wikipedia.org/wiki/File:Unix_history-simple.svg
[4] https://en.wikipedia.org/wiki/Berkeley_Software_Distribution
[5] https://www.mckusick.com/csrg/

Many thanks,

Diomidis Spinellis

PS Thank you all for the help you've provided so far.


From norman at oclsc.org  Mon Jun 16 04:19:36 2014
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 15 Jun 2014 14:19:36 -0400
Subject: [TUHS] Happy birthday, core dumped
Message-ID: <1402856379.23321.for-standards-violators@oclsc.org>

Jay Forrester, who invented core memory, first described it in
a lab notebook 65 years ago today.

(Thanks to the Living Computer Museum, through whose Twitter
feed I learned this tidbit.  It's a place--the real museum,
not just the Twitter feed--many on this list might enjoy:
among their aged-but-working computers are a Xerox Star and
a PDP-7.)

Norman Wilson
Toronto ON


From b4 at gewt.net  Mon Jun 16 22:53:59 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Mon, 16 Jun 2014 08:53:59 -0400 (EDT)
Subject: [TUHS] 4.1BSD Networking
Message-ID: <alpine.OSX.2.00.1406160847210.15321@melanie.local>

Hello all, recent subscriber to this list...but some might 
recognise me.

I'm currently fighting (and mostly succeeding) with getting a pure 
4.3BSD-Tahoe install rolling in a VAX simulator (all my tape drives are 
currently nonfunctional or I'd fire up a real II or III).  Still in the 
middle of compiling (I know there are easier ways...but I like the feeling 
of doing it purely "from scratch"...feels more historically accurate).

Anyways, while waiting for the compile I ended up with a working 4.1c 
installation and I began poking around its source tree (I also did a 
little bit of poking at the CSRG discs).  I stumbled upon the fact 4.1c 
supports the DMC (which SIMH git now emulates!) and I see it's also still 
in src/old on some versions of 4.3 (I wonder if it'll still build...). 
Looking at the source is immensely confusing...does anyone have any 
knowledge/notes from the time period/documentation that will help me with 
my little experiment in archaic networking? I might just be tired...but 
the berknet configuration doesn't make a whole lot of sense to me. 
(There's also the fact my grasp of C is minimal).

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From clemc at ccc.com  Tue Jun 17 00:28:41 2014
From: clemc at ccc.com (Clem Cole)
Date: Mon, 16 Jun 2014 10:28:41 -0400
Subject: [TUHS] 4.1BSD Networking
In-Reply-To: <alpine.OSX.2.00.1406160847210.15321@melanie.local>
References: <alpine.OSX.2.00.1406160847210.15321@melanie.local>
Message-ID: <CAC20D2MRS=0mti5826S+ZF=VzYJL9RF+-xOLLS09Nn-biQn2_A@mail.gmail.com>

Hi Cory,

We can take this a off list if you like.   I warn you the DMR/DMC support
was for BSD was rudimentary, and most of us in the UNIX community did not
mess with it because we had non-DEC Ethernet controllers from that time.
 You might have more success seeing if we can dig up a simulation of the
Interlan or 3Com Unibus boards which were what may of used.

Clem


On Mon, Jun 16, 2014 at 8:53 AM, Cory Smelosky <b4 at gewt.net> wrote:

> Hello all, recent subscriber to this list...but some might recognise me.
>
> I'm currently fighting (and mostly succeeding) with getting a pure
> 4.3BSD-Tahoe install rolling in a VAX simulator (all my tape drives are
> currently nonfunctional or I'd fire up a real II or III).  Still in the
> middle of compiling (I know there are easier ways...but I like the feeling
> of doing it purely "from scratch"...feels more historically accurate).
>
> Anyways, while waiting for the compile I ended up with a working 4.1c
> installation and I began poking around its source tree (I also did a little
> bit of poking at the CSRG discs).  I stumbled upon the fact 4.1c supports
> the DMC (which SIMH git now emulates!) and I see it's also still in src/old
> on some versions of 4.3 (I wonder if it'll still build...). Looking at the
> source is immensely confusing...does anyone have any knowledge/notes from
> the time period/documentation that will help me with my little experiment
> in archaic networking? I might just be tired...but the berknet
> configuration doesn't make a whole lot of sense to me. (There's also the
> fact my grasp of C is minimal).
>
> --
> Cory Smelosky
> http://gewt.net Personal stuff
> http://gimme-sympathy.org Projects
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140616/badc5679/attachment.html>

From ron at ronnatalie.com  Tue Jun 17 02:05:02 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 16 Jun 2014 12:05:02 -0400
Subject: [TUHS] 4.1BSD Networking
In-Reply-To: <CAC20D2MRS=0mti5826S+ZF=VzYJL9RF+-xOLLS09Nn-biQn2_A@mail.gmail.com>
References: <alpine.OSX.2.00.1406160847210.15321@melanie.local>
 <CAC20D2MRS=0mti5826S+ZF=VzYJL9RF+-xOLLS09Nn-biQn2_A@mail.gmail.com>
Message-ID: <A82A739D-BF82-46F2-81D3-20A445C3F1A8@ronnatalie.com>

I'd also warn that 4.1c as originally distriuted  has some serious bugs like crashing when it receives ICMP redirects.    We had just brought our systems up when they crashed and then it crashed an hour later and the phone rang and it was Louis Mamakos of UofM who was playing with their fuzzballs and pinged our system.

From iking at killthewabbit.org  Tue Jun 17 02:13:18 2014
From: iking at killthewabbit.org (iking at killthewabbit.org)
Date: Mon, 16 Jun 2014 09:13:18 -0700
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <1402856379.23321.for-standards-violators@oclsc.org>
References: <1402856379.23321.for-standards-violators@oclsc.org>
Message-ID: <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost>

Small correction: not a Star, an Alto.  :-)  

Sent from my android device.

-----Original Message-----
From: Norman Wilson <norman at oclsc.org>
To: tuhs at minnie.tuhs.org
Sent: Sun, 15 Jun 2014 11:19 AM
Subject: [TUHS] Happy birthday, core dumped

Jay Forrester, who invented core memory, first described it in
a lab notebook 65 years ago today.

(Thanks to the Living Computer Museum, through whose Twitter
feed I learned this tidbit.  It's a place--the real museum,
not just the Twitter feed--many on this list might enjoy:
among their aged-but-working computers are a Xerox Star and
a PDP-7.)

Norman Wilson
Toronto ON
_______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140616/25bde07e/attachment.html>

From b4 at gewt.net  Tue Jun 17 06:37:09 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Mon, 16 Jun 2014 16:37:09 -0400 (EDT)
Subject: [TUHS] Creating 4.3 skeleton filesystem (was Re: 4.1BSD Networking)
In-Reply-To: <A82A739D-BF82-46F2-81D3-20A445C3F1A8@ronnatalie.com>
References: <alpine.OSX.2.00.1406160847210.15321@melanie.local>
 <CAC20D2MRS=0mti5826S+ZF=VzYJL9RF+-xOLLS09Nn-biQn2_A@mail.gmail.com>
 <A82A739D-BF82-46F2-81D3-20A445C3F1A8@ronnatalie.com>
Message-ID: <alpine.OSX.2.00.1406161635210.15321@melanie.local>

Little bit more sidetracking...

How were the skeleton filesystems created when generating a new miniroot 
and whatnot?  Manually?  Were the scripts just removed from Tahoe?

Thanks!

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From gregg.drwho8 at gmail.com  Tue Jun 17 08:01:38 2014
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Mon, 16 Jun 2014 18:01:38 -0400
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost>
References: <1402856379.23321.for-standards-violators@oclsc.org>
 <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost>
Message-ID: <CAC5iaNFwjb9m7g-Uj2D9Vb4514ku9QBuEX7--kyjU0JOkzHBaw@mail.gmail.com>

Hello!
Interesting.
I know I've seen the Star system rig before. But the Xerox Alto one is
new to me. Wasn't the PDP-7 the fellow where UNIX really got its start
on before they moved it to a PDP-11?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Mon, Jun 16, 2014 at 12:13 PM,  <iking at killthewabbit.org> wrote:
> Small correction: not a Star, an Alto.  :-)
>
> Sent from my android device.
>
>
> -----Original Message-----
> From: Norman Wilson <norman at oclsc.org>
> To: tuhs at minnie.tuhs.org
> Sent: Sun, 15 Jun 2014 11:19 AM
> Subject: [TUHS] Happy birthday, core dumped
>
> Jay Forrester, who invented core memory, first described it in
> a lab notebook 65 years ago today.
>
> (Thanks to the Living Computer Museum, through whose Twitter
> feed I learned this tidbit.  It's a place--the real museum,
> not just the Twitter feed--many on this list might enjoy:
> among their aged-but-working computers are a Xerox Star and
> a PDP-7.)
>
> Norman Wilson
> Toronto ON
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>


From cowan at mercury.ccil.org  Tue Jun 17 11:38:40 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 16 Jun 2014 21:38:40 -0400
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <CAC5iaNFwjb9m7g-Uj2D9Vb4514ku9QBuEX7--kyjU0JOkzHBaw@mail.gmail.com>
References: <1402856379.23321.for-standards-violators@oclsc.org>
 <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost>
 <CAC5iaNFwjb9m7g-Uj2D9Vb4514ku9QBuEX7--kyjU0JOkzHBaw@mail.gmail.com>
Message-ID: <20140617013840.GB3947@mercury.ccil.org>

Gregg Levine scripsit:

> I know I've seen the Star system rig before. But the Xerox Alto one is
> new to me. Wasn't the PDP-7 the fellow where UNIX really got its start
> on before they moved it to a PDP-11?

It was.  The 18-bit systems were the red-headed stepchild of the DEC world.
The PDP-1, PDP-4, and PDP-7 systems had no DEC-supplied operating system,
and the PDP-9 only a minimal one, about like OS/8.  Not until the terminal
18-bit system, the PDP-15, were PDP-11 class operating systems provided.
Consequently, the Bell Labs PDP-7 was essentially useless.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Awk!" sed Grep. "A fscking python is perloining my Ruby; let me bash
    him with a Cshell!  Vi didn't I mount it on a troff?" --Francis Turner


From grog at lemis.com  Tue Jun 17 11:56:35 2014
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 17 Jun 2014 11:56:35 +1000
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <20140617013840.GB3947@mercury.ccil.org>
References: <1402856379.23321.for-standards-violators@oclsc.org>
 <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost>
 <CAC5iaNFwjb9m7g-Uj2D9Vb4514ku9QBuEX7--kyjU0JOkzHBaw@mail.gmail.com>
 <20140617013840.GB3947@mercury.ccil.org>
Message-ID: <20140617015635.GB26776@eureka.lemis.com>

On Monday, 16 June 2014 at 21:38:40 -0400, John Cowan wrote:
> Gregg Levine scripsit:
>
>> I know I've seen the Star system rig before. But the Xerox Alto one is
>> new to me. Wasn't the PDP-7 the fellow where UNIX really got its start
>> on before they moved it to a PDP-11?
>
> It was.  The 18-bit systems were the red-headed stepchild of the DEC world.
> The PDP-1, PDP-4, and PDP-7 systems had no DEC-supplied operating system,
> and the PDP-9 only a minimal one, about like OS/8.  Not until the terminal
> 18-bit system, the PDP-15, were PDP-11 class operating systems provided.
> Consequently, the Bell Labs PDP-7 was essentially useless.

Sounds like it was crying out for somebody to write an operating
system for it :-)

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140617/078da89c/attachment.sig>

From iking at killthewabbit.org  Tue Jun 17 13:13:05 2014
From: iking at killthewabbit.org (iking at killthewabbit.org)
Date: Mon, 16 Jun 2014 20:13:05 -0700
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <20140617013840.GB3947@mercury.ccil.org>
References: <1402856379.23321.for-standards-violators@oclsc.org>
 <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost>
 <CAC5iaNFwjb9m7g-Uj2D9Vb4514ku9QBuEX7--kyjU0JOkzHBaw@mail.gmail.com>
 <20140617013840.GB3947@mercury.ccil.org>
Message-ID: <9cea91b5-f4ee-46a3-80b3-899b1ee00d69.maildroid@localhost>

Well, the University of Oregon might disagree with you about the PDP-7.  They ran the DECsys monitor, which ISTR  was the first such software product from DEC outside the 36-bit line (the PDP-6 and -7 were introduced in the same year).  U of O took delivery of their -7 in 1966 and it saw active service for at least three decades, with over thirty doctorates earned based on research performed on the system.  Hardly useless....  

It's always been a bit of a mystery to me why Thompson and Ritchie decided they needed to write a new executive - UNICS - rather than use DECsys.  True, DECsys isn't anything to shout about and Unix is clearly more useful - but IMHO Spacewar! could have been coded in the DECsys 'environment'.  I infer that they saw broader utility and application in a more capable executive - which obviously turned out to be true!  

The U of O PDP-7 is the one currently residing at the Living Computer Museum (I used to maintain it).  

And what's wrong with OS/8?  Minimal, yes - what do you want, Windows Vista?  :-)   - Ian 

Sent from my android device.

-----Original Message-----
From: John Cowan <cowan at mercury.ccil.org>
To: Gregg Levine <gregg.drwho8 at gmail.com>
Cc: tuhs at minnie.tuhs.org
Sent: Mon, 16 Jun 2014 6:38 PM
Subject: Re: [TUHS] Happy birthday, core dumped

Gregg Levine scripsit:

> I know I've seen the Star system rig before. But the Xerox Alto one is
> new to me. Wasn't the PDP-7 the fellow where UNIX really got its start
> on before they moved it to a PDP-11?

It was.  The 18-bit systems were the red-headed stepchild of the DEC world.
The PDP-1, PDP-4, and PDP-7 systems had no DEC-supplied operating system,
and the PDP-9 only a minimal one, about like OS/8.  Not until the terminal
18-bit system, the PDP-15, were PDP-11 class operating systems provided.
Consequently, the Bell Labs PDP-7 was essentially useless.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Awk!" sed Grep. "A fscking python is perloining my Ruby; let me bash
    him with a Cshell!  Vi didn't I mount it on a troff?" --Francis Turner
_______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140616/774d0c77/attachment.html>

From cowan at mercury.ccil.org  Tue Jun 17 22:14:19 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 17 Jun 2014 08:14:19 -0400
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <9cea91b5-f4ee-46a3-80b3-899b1ee00d69.maildroid@localhost>
References: <1402856379.23321.for-standards-violators@oclsc.org>
 <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost>
 <CAC5iaNFwjb9m7g-Uj2D9Vb4514ku9QBuEX7--kyjU0JOkzHBaw@mail.gmail.com>
 <20140617013840.GB3947@mercury.ccil.org>
 <9cea91b5-f4ee-46a3-80b3-899b1ee00d69.maildroid@localhost>
Message-ID: <20140617121419.GD3947@mercury.ccil.org>

iking at killthewabbit.org scripsit:

> Well, the University of Oregon might disagree with you about the PDP-7.
> They ran the DECsys monitor, 

Ah, I didn't know about that.  Still, pretty sub-minimal:  Fortran II,
assembler, editor, period.  It made OS/8 look quite rich by comparison.

> Hardly useless....

However, according to the manual, DECsys required an 8Kword PDP-7, whereas
the "Space Travel" (not "Spacewar!") machine had only 4Kwords.

> And what's wrong with OS/8?  

Nothing.  Indeed, I cut my teeth on it on a PDP-8/M with 8K and a single
DECtape with the driver in ROM.  I was using the term descriptively to
indicate the kind of OS available for the PDP-9.  A modified version also
ran on the '15, it seems.  But the native OSes were DOS-15 (roughly RT-11)
and RSX-15 (a classic DEC RSX).

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
        "Not to know The Smiths is not to know K.X.U."  --K.X.U.


From doug at cs.dartmouth.edu  Wed Jun 18 21:06:54 2014
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 18 Jun 2014 07:06:54 -0400
Subject: [TUHS] Happy birthday, core dumped
Message-ID: <201406181106.s5IB6scu031264@stowe.cs.dartmouth.edu>

> It's always been a bit of a mystery to me why Thompson and Ritchie decided they needed to write a new executive - UNICS - rather than use DECsys.

It was the other way around. They had conceived a clean, simple, yet
powerful, operating system and needed a machine to build it on. A
cast-off PDP-7 happened to be at hand.

Doug


From iking at killthewabbit.org  Thu Jun 19 00:43:51 2014
From: iking at killthewabbit.org (iking at killthewabbit.org)
Date: Wed, 18 Jun 2014 07:43:51 -0700
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <201406181106.s5IB6scu031264@stowe.cs.dartmouth.edu>
References: <201406181106.s5IB6scu031264@stowe.cs.dartmouth.edu>
Message-ID: <ef723f8a-52b6-4810-be59-1837c75b1da3.maildroid@localhost>

Interesting - what's your source?  It was also my understanding they used the -7 'because it was there' but that they had pitched for a PDP-10, which had TOPS-10.  - Ian 

Sent from my android device.

-----Original Message-----
From: Doug McIlroy <doug at cs.dartmouth.edu>
To: tuhs at minnie.tuhs.org
Sent: Wed, 18 Jun 2014 4:06 AM
Subject: Re: [TUHS] Happy birthday, core dumped

> It's always been a bit of a mystery to me why Thompson and Ritchie decided they needed to write a new executive - UNICS - rather than use DECsys.

It was the other way around. They had conceived a clean, simple, yet
powerful, operating system and needed a machine to build it on. A
cast-off PDP-7 happened to be at hand.

Doug
_______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140618/5e94716b/attachment.html>

From crossd at gmail.com  Thu Jun 19 00:48:24 2014
From: crossd at gmail.com (Dan Cross)
Date: Wed, 18 Jun 2014 10:48:24 -0400
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <ef723f8a-52b6-4810-be59-1837c75b1da3.maildroid@localhost>
References: <201406181106.s5IB6scu031264@stowe.cs.dartmouth.edu>
 <ef723f8a-52b6-4810-be59-1837c75b1da3.maildroid@localhost>
Message-ID: <CAEoi9W7GN1zuhpw4MGENSzDdkHYKvdnpHuG0KdSdLKW8oV4hug@mail.gmail.com>

On Wed, Jun 18, 2014 at 10:43 AM, <iking at killthewabbit.org> wrote:

> Interesting - what's your source?  It was also my understanding they used
> the -7 'because it was there' but that they had pitched for a PDP-10, which
> had TOPS-10.  - Ian
>

*laugh*

Doug, weren't you department head at the time, or did that come later?

        - Dan C.


> Sent from my android device.
>
> -----Original Message-----
> From: Doug McIlroy <doug at cs.dartmouth.edu>
> To: tuhs at minnie.tuhs.org
> Sent: Wed, 18 Jun 2014 4:06 AM
> Subject: Re: [TUHS] Happy birthday, core dumped
>
> > It's always been a bit of a mystery to me why Thompson and Ritchie
> decided they needed to write a new executive - UNICS - rather than use
> DECsys.
>
> It was the other way around. They had conceived a clean, simple, yet
> powerful, operating system and needed a machine to build it on. A
> cast-off PDP-7 happened to be at hand.
>
> Doug
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140618/b8f0a9c8/attachment.html>

From norman at oclsc.org  Thu Jun 19 01:03:56 2014
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 18 Jun 2014 11:03:56 -0400
Subject: [TUHS] Happy birthday, core dumped
Message-ID: <1403103840.16031.for-standards-violators@oclsc.org>

  Interesting - what's your source?  It was also my understanding they
  used the -7 'because it was there' but that they had pitched for a
  PDP-10, which had TOPS-10.

======

I think Doug's source is in the class `personal observation.'
He was there at the time; Ken and Dennis's department head, if
I've got it right.

Remember that Bell Labs had just disengaged itself from the
Multics project.  The interest in a new OS sprang partly
from the desire to have a comfortable multi-user system
now that Multics was no longer available.  That's why the
DEC operating systems of the time, which were (as I understand
it) simple single-user monitors, didn't fill the bill.

The character of the players matters too: remember that
Ken is the guy who one night sat down to write a Fortran
compiler because real systems have Fortran, and ended up
inventing B instead.

I've read that there was indeed a pitch to buy a PDP-10; that
there was some complicated plan to lower the effective cost;
and that upper management (not Doug) turned it down because
`Bell Labs doesn't do business that way.'  I think I got that
from Dennis's retrospective paper, published in the 1984
all-UNIX issue of the Bell Labs Techical Journal, a must-read
(along with the late-1970s all-UNIX issue of BSTJ) for anyone
on this list.


From lm at mcvoy.com  Thu Jun 19 00:00:50 2014
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 18 Jun 2014 07:00:50 -0700
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <1403103840.16031.for-standards-violators@oclsc.org>
References: <1403103840.16031.for-standards-violators@oclsc.org>
Message-ID: <20140618140050.GM1580@mcvoy.com>

On Wed, Jun 18, 2014 at 11:03:56AM -0400, Norman Wilson wrote:
> I think I got that
> from Dennis's retrospective paper, published in the 1984
> all-UNIX issue of the Bell Labs Techical Journal, a must-read
> (along with the late-1970s all-UNIX issue of BSTJ) for anyone
> on this list.

Indeed.  I just packed up my office, all the books, and the BSTJ were the
only things I kept close.  Well, that and the Xinu books, I've got a soft
spot for those.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From crossd at gmail.com  Thu Jun 19 01:14:34 2014
From: crossd at gmail.com (Dan Cross)
Date: Wed, 18 Jun 2014 11:14:34 -0400
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <1403103840.16031.for-standards-violators@oclsc.org>
References: <1403103840.16031.for-standards-violators@oclsc.org>
Message-ID: <CAEoi9W4ShqWNvY=Y==NTZNSDbgmj8C5B10DQjaGK4-UTJGFGwg@mail.gmail.com>

The paper with that quote is still linked from dmr's page:
http://cm.bell-labs.com/who/dmr/hist.html



On Wed, Jun 18, 2014 at 11:03 AM, Norman Wilson <norman at oclsc.org> wrote:

>   Interesting - what's your source?  It was also my understanding they
>   used the -7 'because it was there' but that they had pitched for a
>   PDP-10, which had TOPS-10.
>
> ======
>
> I think Doug's source is in the class `personal observation.'
> He was there at the time; Ken and Dennis's department head, if
> I've got it right.
>
> Remember that Bell Labs had just disengaged itself from the
> Multics project.  The interest in a new OS sprang partly
> from the desire to have a comfortable multi-user system
> now that Multics was no longer available.  That's why the
> DEC operating systems of the time, which were (as I understand
> it) simple single-user monitors, didn't fill the bill.
>
> The character of the players matters too: remember that
> Ken is the guy who one night sat down to write a Fortran
> compiler because real systems have Fortran, and ended up
> inventing B instead.
>
> I've read that there was indeed a pitch to buy a PDP-10; that
> there was some complicated plan to lower the effective cost;
> and that upper management (not Doug) turned it down because
> `Bell Labs doesn't do business that way.'  I think I got that
> from Dennis's retrospective paper, published in the 1984
> all-UNIX issue of the Bell Labs Techical Journal, a must-read
> (along with the late-1970s all-UNIX issue of BSTJ) for anyone
> on this list.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140618/373d4631/attachment.html>

From iking at killthewabbit.org  Thu Jun 19 02:21:38 2014
From: iking at killthewabbit.org (Ian King)
Date: Wed, 18 Jun 2014 09:21:38 -0700
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <20140617121419.GD3947@mercury.ccil.org>
References: <1402856379.23321.for-standards-violators@oclsc.org>
 <21ae9091-baed-493a-b84f-ec96efc66955.maildroid@localhost>
 <CAC5iaNFwjb9m7g-Uj2D9Vb4514ku9QBuEX7--kyjU0JOkzHBaw@mail.gmail.com>
 <20140617013840.GB3947@mercury.ccil.org>
 <9cea91b5-f4ee-46a3-80b3-899b1ee00d69.maildroid@localhost>
 <20140617121419.GD3947@mercury.ccil.org>
Message-ID: <B7F9842A-D5E1-4EF9-9FDE-B0F609780528@killthewabbit.org>

On Jun 17, 2014, at 5:14 AM, John Cowan wrote:

> iking at killthewabbit.org scripsit:
>
>> Well, the University of Oregon might disagree with you about the  
>> PDP-7.
>> They ran the DECsys monitor,
>
> Ah, I didn't know about that.  Still, pretty sub-minimal:  Fortran II,
> assembler, editor, period.  It made OS/8 look quite rich by  
> comparison.

U of O also had FOCAL running on it, which may have been a local port  
- I'll have to find out.
>
>> Hardly useless....
>
> However, according to the manual, DECsys required an 8Kword PDP-7,  
> whereas
> the "Space Travel" (not "Spacewar!") machine had only 4Kwords.

Yes, thanks for the correction - a slip of the virtual tongue.  I  
didn't realize the Bell Labs machine was so basic - in fact, it was  
my understanding that the basic machine was 8Kwords.  The machine at  
LCM actually has 16K, with a DEC field mod to allow it to be  
addressed in PDP-9/15 fashion.

>> And what's wrong with OS/8?
>
> Nothing.  Indeed, I cut my teeth on it on a PDP-8/M with 8K and a  
> single
> DECtape with the driver in ROM.  I was using the term descriptively to
> indicate the kind of OS available for the PDP-9.  A modified  
> version also
> ran on the '15, it seems.  But the native OSes were DOS-15 (roughly  
> RT-11)
> and RSX-15 (a classic DEC RSX).

OK, we're good then.  :-)  I have a soft spot for the 12-bit  
machines, if it doesn't show.  -- Ian 


From scj at yaccman.com  Thu Jun 19 02:50:38 2014
From: scj at yaccman.com (scj at yaccman.com)
Date: Wed, 18 Jun 2014 09:50:38 -0700
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <1403103840.16031.for-standards-violators@oclsc.org>
References: <1403103840.16031.for-standards-violators@oclsc.org>
Message-ID: <09fffa6e9f2fdb29ab25825d19594d8e.squirrel@webmail.yaccman.com>

Bell Labs' decision to pull out of Multics still ranks in my mind as one
of the best management decisions I've ever had close contact with...

With respect to Dec's OSs vs Unix, I remember a visit from a Dec repair
person who ran "preventive maintenance" on our disc that wiped out the
file system!  His excuse was that Dec didn't support "permanent storage"
on the disc at the time...



From b4 at gewt.net  Thu Jun 19 02:58:45 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Wed, 18 Jun 2014 12:58:45 -0400
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <20140618140050.GM1580@mcvoy.com>
References: <1403103840.16031.for-standards-violators@oclsc.org>
 <20140618140050.GM1580@mcvoy.com>
Message-ID: <B557B27B-9EEF-4FD5-B652-32D14B814167@gewt.net>



Sent from my advertising assimilation device

> On 18 Jun 2014, at 10:00, Larry McVoy <lm at mcvoy.com> wrote:
> 
>> On Wed, Jun 18, 2014 at 11:03:56AM -0400, Norman Wilson wrote:
>> I think I got that
>> from Dennis's retrospective paper, published in the 1984
>> all-UNIX issue of the Bell Labs Techical Journal, a must-read
>> (along with the late-1970s all-UNIX issue of BSTJ) for anyone
>> on this list.
> 
> Indeed.  I just packed up my office, all the books, and the BSTJ were the
> only things I kept close.  Well, that and the Xinu books, I've got a soft
> spot for those.

Have Xinu media to go with it? It's something I've been trying to track down. ;)


> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From lm at mcvoy.com  Thu Jun 19 01:55:24 2014
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 18 Jun 2014 08:55:24 -0700
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <B557B27B-9EEF-4FD5-B652-32D14B814167@gewt.net>
References: <1403103840.16031.for-standards-violators@oclsc.org>
 <20140618140050.GM1580@mcvoy.com>
 <B557B27B-9EEF-4FD5-B652-32D14B814167@gewt.net>
Message-ID: <20140618155524.GR1580@mcvoy.com>

On Wed, Jun 18, 2014 at 12:58:45PM -0400, Cory Smelosky wrote:
> 
> 
> Sent from my advertising assimilation device
> 
> > On 18 Jun 2014, at 10:00, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> >> On Wed, Jun 18, 2014 at 11:03:56AM -0400, Norman Wilson wrote:
> >> I think I got that
> >> from Dennis's retrospective paper, published in the 1984
> >> all-UNIX issue of the Bell Labs Techical Journal, a must-read
> >> (along with the late-1970s all-UNIX issue of BSTJ) for anyone
> >> on this list.
> > 
> > Indeed.  I just packed up my office, all the books, and the BSTJ were the
> > only things I kept close.  Well, that and the Xinu books, I've got a soft
> > spot for those.
> 
> Have Xinu media to go with it? It's something I've been trying to track down. ;)

Have you asked Doug?  I've copied him (Hey Doug, you should be on this list,
all the long time unix nerds seem to be here, lots of fun with memory lane).

Cheers,

--lm


From a.phillip.garcia at gmail.com  Thu Jun 19 04:21:30 2014
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Wed, 18 Jun 2014 13:21:30 -0500
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <ef723f8a-52b6-4810-be59-1837c75b1da3.maildroid@localhost>
References: <201406181106.s5IB6scu031264@stowe.cs.dartmouth.edu>
 <ef723f8a-52b6-4810-be59-1837c75b1da3.maildroid@localhost>
Message-ID: <CAFCBnZu8wS4WmwuAK8+MhyE5W-N_-RtubSeJuG-1jnWxiXDWug@mail.gmail.com>

On Wed, Jun 18, 2014 at 9:43 AM,  <iking at killthewabbit.org> wrote:
> Interesting - what's your source?

:-)
that's like asking george martin for his source regarding a beatles song...


From cowan at mercury.ccil.org  Thu Jun 19 04:43:41 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Wed, 18 Jun 2014 14:43:41 -0400
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <09fffa6e9f2fdb29ab25825d19594d8e.squirrel@webmail.yaccman.com>
References: <1403103840.16031.for-standards-violators@oclsc.org>
 <09fffa6e9f2fdb29ab25825d19594d8e.squirrel@webmail.yaccman.com>
Message-ID: <20140618184341.GC19046@mercury.ccil.org>

scj at yaccman.com scripsit:

> With respect to Dec's OSs vs Unix, I remember a visit from a Dec repair
> person who ran "preventive maintenance" on our disc that wiped out the
> file system!  His excuse was that Dec didn't support "permanent storage"
> on the disc at the time...

Next time, mount a scratch monkey.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
The penguin geeks is happy / As under the waves they lark
The closed-source geeks ain't happy / They sad cause they in the dark
But geeks in the dark is lucky / They in for a worser treat
One day when the Borg go belly-up / Guess who wind up on the street.


From jnc at mercury.lcs.mit.edu  Thu Jun 19 07:21:38 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 18 Jun 2014 17:21:38 -0400 (EDT)
Subject: [TUHS] Happy birthday, core dumped
Message-ID: <20140618212138.03B9218C13A@mercury.lcs.mit.edu>

    > From: "A. P. Garcia" <a.phillip.garcia at gmail.com>

    > that's like asking george martin for his source regarding a beatles
    > song...

Reminds me of the person on Wikipedia who tried to argue with me about the
'History of the Internet' article... :-)


    > From: John Cowan <cowan at mercury.ccil.org>

    >> scj at yaccman.com scripsit:

    >> a Dec repair person who ran "preventive maintenance" on our disc that
    >> wiped out the file system! His excuse was that Dec didn't support
    >> "permanent storage" on the disc at the time...

    > Next time, mount a scratch monkey.

It was probably a fixed-head disk (RS11 or RS04); can't exactly stick a
different pack in! :-) Probably the DEC OS's only used it for swapping or
something, since they were both relatively small - 512KB.

(Speaking of RS11's: the first PDP-11 I used - an 11/20 running RSTS - had a
grand total disk storage of _one_ RS11!)


And speaking of putting file systems on them: I recently wrote this command
for V6 called 'si' which allowed me (among many other interesting things) to
watch the contents of the disk buffer(s). It turns out that even with other
packs mounted, the buffer is almost always completely full of blocks from the
root device; it makes plain the value of having the root on a _really_
fast disk. 

I don't know if that usage pattern is because /bin is there, or because pipes
get created on the root, or what. When I get up the energy I'll move /bin to
another drive (yeah, yeah, I know - good way to lose and create a systen that
won't boot, so I'll actually make a _copy_ of /bin and mount it _over_ the
original /bin - probably a host of interesting errors there, e.g. if a process
has the old /bin as its current dir), and see what the cache contents look
like then.

	Noel


From milov at cs.uwlax.edu  Tue Jun 17 08:20:24 2014
From: milov at cs.uwlax.edu (=?utf-8?Q?Milo_Velimirovi=C4=87?=)
Date: Mon, 16 Jun 2014 17:20:24 -0500
Subject: [TUHS] pdp11 available
Message-ID: <C487C03D-D7E0-4124-8E87-821B99661E8D@cs.uwlax.edu>

Greetings,

I have a pdp11/84 and various peripherals available to whomever is willing to take them. I'm in La Crosse, Wisconsin, USA.

pdp11/84
RX01

TU80

2 cabs of 2ea RA81

Thanks,
Milo

--
Milo Velimirović
La Crosse, Wisconsin 54601 USA   43 48 48 N 91 13 53 W







From comer at cs.purdue.edu  Thu Jun 19 03:48:10 2014
From: comer at cs.purdue.edu (Douglas Comer)
Date: Wed, 18 Jun 2014 13:48:10 -0400 (EDT)
Subject: [TUHS] Happy birthday, core dumped
Message-ID: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu>

  > > Have Xinu media to go with it? It's something I've been trying to track down. ;)
  > 
  > Have you asked Doug?  I've copied him

I just donated my extra copy of Xinu tapes and floppies to the computer museum
(along with first editions of the books).

  > (Hey Doug, you should be on this list, all the long time unix nerds seem to be
  > here, lots of fun with memory lane).

I'd be happy to join.

Doug



From wkt at tuhs.org  Thu Jun 19 08:23:16 2014
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 19 Jun 2014 08:23:16 +1000
Subject: [TUHS] Xinu
In-Reply-To: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu>
References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu>
Message-ID: <b933c089-91f4-433c-9337-4eeb78c44d17@email.android.com>

I should mention that I "ported"  Xinu over to the  Apple ] [ when I was at  uni: I transliterated the C code into assembly and used an external 555 timer to generate the  clock ticks. Fun times! 

      Warren 
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140619/a353fc6f/attachment.html>

From tim.newsham at gmail.com  Thu Jun 19 08:33:15 2014
From: tim.newsham at gmail.com (Tim Newsham)
Date: Wed, 18 Jun 2014 12:33:15 -1000
Subject: [TUHS] Xinu
In-Reply-To: <b933c089-91f4-433c-9337-4eeb78c44d17@email.android.com>
References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu>
 <b933c089-91f4-433c-9337-4eeb78c44d17@email.android.com>
Message-ID: <CAGSRWbgJ6DPbV9aF312_pdDf9YyfR85yBB_JoM--pRLHy7k6wg@mail.gmail.com>

is your code available?  does it run on any of the modern apple][ emus?

On Wed, Jun 18, 2014 at 12:23 PM, Warren Toomey <wkt at tuhs.org> wrote:
> I should mention that I "ported" Xinu over to the Apple ] [ when I was at
> uni: I transliterated the C code into assembly and used an external 555
> timer to generate the clock ticks. Fun times!
>
> Warren
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>



-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com


From lm at mcvoy.com  Thu Jun 19 07:17:14 2014
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 18 Jun 2014 14:17:14 -0700
Subject: [TUHS] Xinu
In-Reply-To: <b933c089-91f4-433c-9337-4eeb78c44d17@email.android.com>
References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu>
 <b933c089-91f4-433c-9337-4eeb78c44d17@email.android.com>
Message-ID: <20140618211714.GD17033@mcvoy.com>

On Thu, Jun 19, 2014 at 08:23:16AM +1000, Warren Toomey wrote:
> I should mention that I "ported"  Xinu over to the  Apple ] [ when
> I was at  uni: I transliterated the C code into assembly and used an
> external 555 timer to generate the  clock ticks. Fun times!

I loved Xinu, it was sort of like the legal Lions book with source code.
And Comer's coding style is pretty similar to mine, simple obvious stuff
for 99% of the code, you only got clever when it was actually important.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From a.phillip.garcia at gmail.com  Thu Jun 19 08:39:20 2014
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Wed, 18 Jun 2014 17:39:20 -0500
Subject: [TUHS] Xinu
In-Reply-To: <b933c089-91f4-433c-9337-4eeb78c44d17@email.android.com>
References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu>
 <b933c089-91f4-433c-9337-4eeb78c44d17@email.android.com>
Message-ID: <CAFCBnZvVBiEce+sK7Qre+UDC=QQ6uqi5ykL45HEP6MeDpmYHvg@mail.gmail.com>

On Jun 18, 2014 5:24 PM, "Warren Toomey" <wkt at tuhs.org> wrote:
>
> I should mention that I "ported" Xinu over to the Apple ] [ when I was at
uni: I transliterated the C code into assembly and used an external 555
timer to generate the clock ticks. Fun times!
>
> Warren
> --

nice! i have the lsi-11 editions (1984) of the xinu approach on my shelf,
up through the linksys edition (2012). i've spent a small fortune on his
books, second only to tanenbaum, i would think. (not a terribly big
stallings fan, but he's certainly prolific.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140618/b7e236f3/attachment.html>

From b4 at gewt.net  Thu Jun 19 08:38:37 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Wed, 18 Jun 2014 18:38:37 -0400 (EDT)
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu>
References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu>
Message-ID: <alpine.DEB.2.10.1406181837100.4164@melanie>

On Wed, 18 Jun 2014, Douglas Comer wrote:

>  > > Have Xinu media to go with it? It's something I've been trying to track down. ;)
>  >
>  > Have you asked Doug?  I've copied him
>
> I just donated my extra copy of Xinu tapes and floppies to the computer museum
> (along with first editions of the books).
>

Ahh!  I wonder if they'll be making images and PDFs available?

>  > (Hey Doug, you should be on this list, all the long time unix nerds seem to be
>  > here, lots of fun with memory lane).
>
> I'd be happy to join.
>

It seems like a place that'll help with my crazy projects, too.

> Doug
>
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From wkt at tuhs.org  Thu Jun 19 08:42:26 2014
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 19 Jun 2014 08:42:26 +1000
Subject: [TUHS] Xinu
In-Reply-To: <CAGSRWbgJ6DPbV9aF312_pdDf9YyfR85yBB_JoM--pRLHy7k6wg@mail.gmail.com>
References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu>
 <b933c089-91f4-433c-9337-4eeb78c44d17@email.android.com>
 <CAGSRWbgJ6DPbV9aF312_pdDf9YyfR85yBB_JoM--pRLHy7k6wg@mail.gmail.com>
Message-ID: <20140618224226.GA9897@www.oztivo.net>

> On Wed, Jun 18, 2014 at 12:23 PM, Warren Toomey <wkt at tuhs.org> wrote:
> > I should mention that I "ported" Xinu over to the Apple ] [ when I was at
> > uni: I transliterated the C code into assembly and used an external 555
> > timer to generate the clock ticks. Fun times!

On Wed, Jun 18, 2014 at 12:33:15PM -1000, Tim Newsham wrote:
> is your code available?  does it run on any of the modern apple][ emus?

It's available at ftp://minnie.tuhs.org/pub/apple2/apple2xinu.tar.gz with
source code, binaries, floopy images and some documentation.

No, it won't run on a real Apple ][ without some work. I actually wrote
it for an Apple clone which had bank-switched RAM and I made use of that
to hide the BASIC ROM and store the OS in the upper 12K. You would also
need to simulate a 10 or 20Hz NMI as well :-)

Cheers,
	Warren


From reed at reedmedia.net  Thu Jun 19 08:55:05 2014
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Wed, 18 Jun 2014 17:55:05 -0500 (CDT)
Subject: [TUHS] Tree of late BSD releases
In-Reply-To: <539DB1D4.3080909@aueb.gr>
References: <539DB1D4.3080909@aueb.gr>
Message-ID: <alpine.NEB.2.02.1406181643500.22854@t1.m.reedmedia.net>

On Sun, 15 Jun 2014, Diomidis Spinellis wrote:

> First, consider this widely reproduced BSD family tree [2].  It has 
> 4.4BSD-Encumbered derive from a line that includes Net/1, which was 
> freely redistributable.  Wouldn't it be clearer to create two 
> branches, one with distributions free of AT&T code (4.3 BSD Net/1, 4.3 
> BSD Net/2, 4.4 BSD Lite1, 4.4 BSD Lite2) and one with full 
> distributions (4.4 BSD, ...)?

I don't have any preference on that.

>  On which side would Tahoe and Reno stand?

Tahoe included both the proprietary code and the code which could "be 
freely redistributed". The same with Reno, which was also "within the 
usual licensing constraints" (as it still had the proprietary code).

> Also, the same tree [2] shows 4.4 BSD having as its ancestor 4.3 BSD 
> Net/2, whereas another tree depicted on Wikipedia [3] has shows 4.4 
> BSD and 4.3 BSD Net/2 having as their ancestor 4.3 BSD Reno.  What's 
> the correct genealogy?

Note that Net/2 was not a complete or ready-to-use system, so a better 
genealogy (than those two) may be like:

4.3BSD Reno
  |      \
  |       \
  |      4.3BSD NET/2
  |       /
  |      /
4.4BSD Alpha 

> Finally, I have a conflict with release dates.  Wikipedia gives the 
> following dates for Tahoe and Net/1 [4]:
> 
> 4.3 BSD Tahoe June 1988

Announced in June 1988 (see admin/postings/4BSD/INDEX) but even users 
outside of Berkeley reported bugs specifically against "Tahoe" source  
tree as early as at least May 1987 (see admin/bugs/4.3BSD-tahoe/).

> 4.3 BSD Net/1 June 1989

That date is in McKusick's open sources chapter, but the "Yesterday, 
Today and Tomorrow" article says Spring 1988. It was announced in 
November/December 1988 (see admin/postings/4BSD/V1/73 and the 
/admin/postings/4BSD/INDEX). (930108.oppose.txt also says was 
distributed in 1988.) (Two Salus books also mention that it was 
announced at the BSD Workshop in Nov. 1988 to be available.)

As for dates for the files, they were probably still updated even after 
initially released (which you can see in other releases too).



From cowan at mercury.ccil.org  Thu Jun 19 08:55:28 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Wed, 18 Jun 2014 18:55:28 -0400
Subject: [TUHS] Happy birthday, core dumped
In-Reply-To: <20140618212138.03B9218C13A@mercury.lcs.mit.edu>
References: <20140618212138.03B9218C13A@mercury.lcs.mit.edu>
Message-ID: <20140618225528.GF19046@mercury.ccil.org>

Noel Chiappa scripsit:

> Reminds me of the person on Wikipedia who tried to argue with me about the
> 'History of the Internet' article... :-)

To be fair, Wikipedia is supposed to be based on secondary sources.  Your
memories are a nullary source.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
BALIN FUNDINUL          UZBAD KHAZADDUMU
BALIN SON OF FUNDIN     LORD OF KHAZAD-DUM


From corey at lod.com  Thu Jun 19 08:54:15 2014
From: corey at lod.com (Corey Lindsly)
Date: Wed, 18 Jun 2014 15:54:15 -0700 (PDT)
Subject: [TUHS] Xinu
In-Reply-To: <20140618224226.GA9897@www.oztivo.net>
Message-ID: <20140618225415.07A2740F3@lod.com>


> No, it won't run on a real Apple ][ without some work. I actually wrote
> it for an Apple clone which had bank-switched RAM and I made use of that

Franklin Ace? I had one of those. Probably still do, somewhere.

--corey



From doug at cs.dartmouth.edu  Thu Jun 19 11:49:48 2014
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 18 Jun 2014 21:49:48 -0400
Subject: [TUHS] Happy birthday, core dumped
Message-ID: <201406190149.s5J1nmP1004744@stowe.cs.dartmouth.edu>

They pitched a PDP-10 for a similar reason--hardware to build a
bigger Unix on. When a small pot of end-of-year money appeared,
they took a PDP-11 instead--serendipitously, because university
folks started proving this elegant system on cheap hardware
in many projects in small labs, which they never could have
done had the system existed on a PDP-10 mainframe. While
upper management did not directly cause Unix to be built,
their decisions to abandon Multics and not to buy a PDP-10
were notable causes for its creation and spread.

Doug


> Date: Wed, 18 Jun 2014 07:43:51 -0700
> From: iking at killthewabbit.org
> To: tuhs at minnie.tuhs.org,Doug McIlroy <doug at cs.dartmouth.edu>
> Subject: Re: [TUHS] Happy birthday, core dumped
> Message-ID: <ef723f8a-52b6-4810-be59-1837c75b1da3.maildroid at localhost>
> Content-Type: text/plain; charset="utf-8"
> 
> Interesting - what's your source?  It was also my understanding they used the -7 'because it was there' but that they had pitched for a PDP-10, which had TOPS-10.  - Ian
> 
> Sent from my android device.
> 
> -----Original Message-----
> From: Doug McIlroy <doug at cs.dartmouth.edu>
> To: tuhs at minnie.tuhs.org
> Sent: Wed, 18 Jun 2014 4:06 AM
> Subject: Re: [TUHS] Happy birthday, core dumped
> 
> 
> > It's always been a bit of a mystery to me why Thompson and Ritchie decided they needed to write a new executive - UNICS - rather than use DECsys.
> 
> It was the other way around. They had conceived a clean, simple, yet
> powerful, operating system and needed a machine to build it on. A
> cast-off PDP-7 happened to be at hand.
> 
> Doug


From cjsvance at gmail.com  Thu Jun 19 14:17:27 2014
From: cjsvance at gmail.com (Christopher Vance)
Date: Thu, 19 Jun 2014 14:17:27 +1000
Subject: [TUHS] Xinu
In-Reply-To: <20140618225415.07A2740F3@lod.com>
References: <20140618224226.GA9897@www.oztivo.net>
 <20140618225415.07A2740F3@lod.com>
Message-ID: <CA+Z8kA4fcdUrBpATqNgoSTc17Zpp2ywbbuaWSdAw0FJpMuU0gg@mail.gmail.com>

I ported Xinu to a Motorola 68000 on VME card. I had the luxury of a
working C compiler, so there was very little assembly language required
(context switch only, from memory). The main effort was in rewriting device
drivers for the relevant hardware. The result was used for teaching
Operating Systems.

Unfortunately, I no longer have the code.


On Thu, Jun 19, 2014 at 8:54 AM, Corey Lindsly <corey at lod.com> wrote:

>
> > No, it won't run on a real Apple ][ without some work. I actually wrote
> > it for an Apple clone which had bank-switched RAM and I made use of that
>
> Franklin Ace? I had one of those. Probably still do, somewhere.
>
> --corey
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>



-- 
Christopher Vance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140619/4f355f97/attachment.html>

From usotsuki at buric.co  Thu Jun 19 14:39:48 2014
From: usotsuki at buric.co (Steve Nickolas)
Date: Thu, 19 Jun 2014 04:39:48 +0000 (UTC)
Subject: [TUHS] Xinu
In-Reply-To: <20140618224226.GA9897@www.oztivo.net>
References: <201406181748.s5IHmAjO011186@lancelot.cs.purdue.edu>
 <b933c089-91f4-433c-9337-4eeb78c44d17@email.android.com>
 <CAGSRWbgJ6DPbV9aF312_pdDf9YyfR85yBB_JoM--pRLHy7k6wg@mail.gmail.com>
 <20140618224226.GA9897@www.oztivo.net>
Message-ID: <alpine.DEB.2.02.1406190438350.87519@localhost>

On Thu, 19 Jun 2014, Warren Toomey wrote:

>> On Wed, Jun 18, 2014 at 12:23 PM, Warren Toomey <wkt at tuhs.org> wrote:
>>> I should mention that I "ported" Xinu over to the Apple ] [ when I was at
>>> uni: I transliterated the C code into assembly and used an external 555
>>> timer to generate the clock ticks. Fun times!
>
> On Wed, Jun 18, 2014 at 12:33:15PM -1000, Tim Newsham wrote:
>> is your code available?  does it run on any of the modern apple][ emus?
>
> It's available at ftp://minnie.tuhs.org/pub/apple2/apple2xinu.tar.gz with
> source code, binaries, floopy images and some documentation.
>
> No, it won't run on a real Apple ][ without some work. I actually wrote
> it for an Apple clone which had bank-switched RAM and I made use of that
> to hide the BASIC ROM and store the OS in the upper 12K. You would also
> need to simulate a 10 or 20Hz NMI as well :-)

Well, I usually assume an Apple ][ at least has THAT ability (as any with 
at least 64K will) :P, but the NMI issue would be the problem. :/

-uso.


From comer at cs.purdue.edu  Fri Jun 20 23:05:34 2014
From: comer at cs.purdue.edu (Douglas Comer)
Date: Fri, 20 Jun 2014 09:05:34 -0400
Subject: [TUHS] Happy birthday, core dumped
Message-ID: <BE9CFA2D-8F67-4E64-A7C3-A3327A38D145@cs.purdue.edu>


> Ahh!  I wonder if they'll be making images and PDFs available?

If you want to check, my contact has been:

	 William Harnack <wharnack at computerhistory.org>

Doug



From wkt at tuhs.org  Sat Jun 28 17:02:06 2014
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 28 Jun 2014 17:02:06 +1000
Subject: [TUHS] 40 years of Unix CACM Article
In-Reply-To: <alpine.BSF.2.00.1406281612530.78267@aneurin.horsfall.org>
References: <alpine.BSF.2.00.1406281612530.78267@aneurin.horsfall.org>
Message-ID: <db36c562-c56f-4e71-a1c6-8f0e2f138e53@email.android.com>

Just in from an early Unix devotee.
   Warren


-------- Original Message --------
From: Dave Horsfall <dave at horsfall.org>
Sent: 28 June 2014 16:14:18 AEST
To: Auug Talk <talk at lists.auug.org.au>
Subject: [AUUG-Talk]: 40 years of Unix

Next month sees the 40th anniversary of the article "The Unix Timesharing 
System" published in Communications of the ACM; I was at UNSW at the time, 
and we bought the first tape for subsequent distribution.

At the time its only competitor was RSTS-11, and to a lesser extent 
RSX-11D and RSX-11M (all DEC systems).  It saw CP/M vanish, MS-DOS come 
and go, NT tried to challenge it, and even Windows hasn't beaten it.

It spawned Linux, which Billy Gates regarded as a serious threat ("any box 
running Linux is not running Windows") and even tried a smear campaign 
against it.

Unix was a design that "just worked" because K&R simply got it right, 
right from the start.

It'll never go away.

-- Dave
_______________________________________________
Applix 1616 mailing list
Applix-L at object-craft.com.au
https://www.object-craft.com.au/cgi-bin/mailman/listinfo/applix-l
_______________________________________________
Talk - The AUUG discussion list.
Talk at lists.auug.org.au
https://lists.auug.org.au/listinfo/talk

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140628/47943fef/attachment.html>

From wkt at tuhs.org  Sat Jun 28 17:28:11 2014
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 28 Jun 2014 17:28:11 +1000
Subject: [TUHS] 40 years of Unix CACM Article
In-Reply-To: <60AED4C0-D500-4666-823C-F61D929BA7B0@ieee.org>
References: <alpine.BSF.2.00.1406281612530.78267@aneurin.horsfall.org>
 <db36c562-c56f-4e71-a1c6-8f0e2f138e53@email.android.com>
 <60AED4C0-D500-4666-823C-F61D929BA7B0@ieee.org>
Message-ID: <20944a6d-6edc-480e-8563-730e5b243cc4@email.android.com>

Knowing Dave and his long history with Unix, I suspect it was simply a typo. Just like vi commands are now hardwired into my fingers, I guess K&R is imprinted on his fingers.
Cheers, Warren

On 28 June 2014 17:12:14 AEST, Armando Stettner <aps at ieee.org> wrote:
>K&R usually refers to Brian Kernighan and Dennis Ritchie, writers of
>the (I think) first book on C.  If there were two people to acknowledge
>for getting it right, it would be Ken and Dennis.
>
>  aps
>
>
>Begin forwarded message:
>
>> From: Warren Toomey <wkt at tuhs.org>
>> Subject: [TUHS] 40 years of Unix CACM Article
>> Date: June 28, 2014 at 12:02:06 AM PDT
>> To: tuhs at tuhs.org
>> 
>> Just in from an early Unix devotee.
>> Warren
>> 
>> From: Dave Horsfall <dave at horsfall.org>
>> Sent: 28 June 2014 16:14:18 AEST
>> To: Auug Talk <talk at lists.auug.org.au>
>> Subject: [AUUG-Talk]: 40 years of Unix
>> 
>> Next month sees the 40th anniversary of the article "The Unix
>Timesharing 
>> System" published in Communications of the ACM; I was at UNSW at the
>time, 
>> and we bought the first tape for subsequent distribution.
>> 
>> At the time its only competitor was RSTS-11, and to a lesser extent 
>> RSX-11D and RSX-11M (all DEC systems).  It saw CP/M vanish, MS-DOS
>come 
>> and go, NT tried to challenge it, and even Windows hasn't beaten it.
>> 
>> It spawned Linux, which Billy Gates regarded as a serious threat
>("any box 
>> running Linux is not running Windows") and even tried a smear
>campaign 
>> against it.
>> 
>> Unix was a design that "just worked" because K&R simply got it right,
>
>> right from the start.
>> 
>> It'll never go away.
>> 
>> -- Dave
>> 
>> Applix 1616 mailing list
>> Applix-L at object-craft.com.au
>> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/applix-l
>> 
>> Talk - The AUUG discussion list.
>> Talk at lists.auug.org.au
>> https://lists.auug.org.au/listinfo/talk
>> 
>> -- 
>> Sent from my Android phone with K-9 Mail. Please excuse my
>brevity._______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140628/04a8e086/attachment.html>

