The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Setting up an X Development Environment for Mac OS
@ 2023-01-25  1:46 Will Senn
  2023-01-25  7:45 ` [TUHS] " segaloco via TUHS
  0 siblings, 1 reply; 39+ messages in thread
From: Will Senn @ 2023-01-25  1:46 UTC (permalink / raw)
  To: TUHS main list

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

All,

If you think unix ends without x, just move along, nothing to see here. 
Otherwise, I thought I would share the subject of my latest post and a 
link with those of you interested in such things.

Recently, I've been tooling around trying to wrap my head around x 
windows and wanted to give programming it a shot at the xlib level... on 
my mac, if possible. So, I bought a copy of Adrian Nye's Xlib 
Programming Manual for Version 11 R4/R5, aka Volume One of The 
Definitive Guides to the X Window System, published, get this... 30+ 
years ago, in 1992 :) and started reading like a madman. As usual, this 
was an example of great technical writing from the prior millenium, 
something rarely found today.

Anyway, I hunted up the source code examples as published, unpacked 
them, did a few environmental things to my mac, and built my first xlib 
application from that source. A few tweaks to my XQuartz configuration 
and I was running the application in twm on my mac, with a root window.

To read about it and see it in all of its glory, check it out here:

https://decuser.github.io/operating-systems/mojave/x-windows/2023/01/24/x-windows-dev-on-mac.html

The same sort of setup works with Linux, FreeBSD, or my latest 
environment DragonFly BSD. It's not the environment that I find 
interesting, but rather the X Window System itself, but this is my way 
of entering into that world. If you are interested in running X Windows, 
not as an integrated system on your mac (where x apps run in aqua 
windows), but with a 'regular' window manager, and you haven't figured 
out how, this is one way.

On the provocateur front - is X part of unix? I mean this in oh so many 
nuanced ways, so read into it as you will. I would contend, torpedoes be 
damned, that it is :).

Will

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25  1:46 [TUHS] Setting up an X Development Environment for Mac OS Will Senn
@ 2023-01-25  7:45 ` segaloco via TUHS
  2023-01-25  8:00   ` Lars Brinkhoff
  2023-01-25 16:41   ` Rich Salz
  0 siblings, 2 replies; 39+ messages in thread
From: segaloco via TUHS @ 2023-01-25  7:45 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

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

I suspect even what with Wayland making the rounds, there'll probably be X around for a looooong time. My guess anyway. I just recently built an X setup from scratch on Linux, it wasn't too much of a pain save that the protocol headers have merged into the xorgproto package. I didn't realize this until I had already installed older versions of all the individual packages.

I was surprised to learn in the process that xterm is not distributed by XOrg, but by someone else. It even features in the default xdm session along with xconsole and xsm, so certainly considered a standard component of X, but distributed and maintained independently it seems.

Aa for the questions of the UNIX-ness of X, it started in Athena, which as I understand it was supposed to be relatively OS-agnostic distributed computing? In any case, the predecessor ran on a different OS, not sure how significant that is to the genesis of what would be called X or what OS it "started" on.

Aside from the ubiquitous X books (which I mean to add to my library...) USL also shipped a handful of books with SVR4 concerning both X and NeWS. I've only got the Xlib one but it seems to cover the basics pretty well. I'd be curious to compare it to the other set. One of these days I mean to round out that SVR4 documentation set.

There were probably materials in the SVR4.2 era as well but I haven't focused as much on those books. Dunno what if any documentation Novell then Caldera/SCO kept up with. I'd love a fresh round of print books, I much prefer paper for reference, but nowadays new tech material is most certainly second/third-hand rather than thoughtfully crafted by the team and those adjacent to whatever is being described. I love me a good primary source....

I've played with XQuartz a bit, mainly remote X from one of my Linux boxes. Kinda slow...but I did zero tuning so not sure what the expected performance of X-over-ssh is. In any case, given the ubiquity, I doubt we'll see X going anywhere soon, and even when it does eventually start to sunset, there'll probably be shims and wrappers for compatibility for a while longer. Plus, I don't know what the prospects are regarding Wayland and SVR4 derivs, but they're all happily running X still, and aren't necessarily getting any new large-scale development love, so likely will ride out with X.

- Matt G.
------- Original Message -------
On Tuesday, January 24th, 2023 at 5:46 PM, Will Senn <will.senn@gmail.com> wrote:

> All,
>
> If you think unix ends without x, just move along, nothing to see here. Otherwise, I thought I would share the subject of my latest post and a link with those of you interested in such things.
>
> Recently, I've been tooling around trying to wrap my head around x windows and wanted to give programming it a shot at the xlib level... on my mac, if possible. So, I bought a copy of Adrian Nye's Xlib Programming Manual for Version 11 R4/R5, aka Volume One of The Definitive Guides to the X Window System, published, get this... 30+ years ago, in 1992 :) and started reading like a madman. As usual, this was an example of great technical writing from the prior millenium, something rarely found today.
>
> Anyway, I hunted up the source code examples as published, unpacked them, did a few environmental things to my mac, and built my first xlib application from that source. A few tweaks to my XQuartz configuration and I was running the application in twm on my mac, with a root window.
>
> To read about it and see it in all of its glory, check it out here:
>
> https://decuser.github.io/operating-systems/mojave/x-windows/2023/01/24/x-windows-dev-on-mac.html
>
> The same sort of setup works with Linux, FreeBSD, or my latest environment DragonFly BSD. It's not the environment that I find interesting, but rather the X Window System itself, but this is my way of entering into that world. If you are interested in running X Windows, not as an integrated system on your mac (where x apps run in aqua windows), but with a 'regular' window manager, and you haven't figured out how, this is one way.
>
> On the provocateur front - is X part of unix? I mean this in oh so many nuanced ways, so read into it as you will. I would contend, torpedoes be damned, that it is :).
>
> Will

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25  7:45 ` [TUHS] " segaloco via TUHS
@ 2023-01-25  8:00   ` Lars Brinkhoff
  2023-01-25 16:41   ` Rich Salz
  1 sibling, 0 replies; 39+ messages in thread
From: Lars Brinkhoff @ 2023-01-25  8:00 UTC (permalink / raw)
  To: segaloco via TUHS; +Cc: segaloco

segaloco wrote:
> A[s] for the questions of the UNIX-ness of X, it started in Athena

It's my understanding it was started by Bob Scheifler of the CLU group.
It was soon picked up by Jim Gettys and Project Athena.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25  7:45 ` [TUHS] " segaloco via TUHS
  2023-01-25  8:00   ` Lars Brinkhoff
@ 2023-01-25 16:41   ` Rich Salz
  2023-01-25 19:53     ` Theodore Ts'o
  1 sibling, 1 reply; 39+ messages in thread
From: Rich Salz @ 2023-01-25 16:41 UTC (permalink / raw)
  To: segaloco; +Cc: TUHS main list

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

> Aa for the questions of the UNIX-ness of X, it started in Athena, which as
> I understand it was supposed to be relatively OS-agnostic distributed
> computing? In any case, the predecessor ran on a different OS, not sure how
> significant that is to the genesis of what would be called X or what OS it
> "started" on.
>

Athena was about scaling up Unix workstations. It was started with grants
from IBM and Digital. It was never OS-agnostic.

You can find a brief history of X at
https://www.oreilly.com/library/view/x-power-tools/9780596101954/ch01.html,
and the Wikipedia article on the X Window System is pretty good; reed the
"History" section.

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25 16:41   ` Rich Salz
@ 2023-01-25 19:53     ` Theodore Ts'o
  2023-01-25 20:04       ` Dan Cross
  2023-01-26 13:17       ` Marc Donner
  0 siblings, 2 replies; 39+ messages in thread
From: Theodore Ts'o @ 2023-01-25 19:53 UTC (permalink / raw)
  To: Rich Salz; +Cc: segaloco, TUHS main list

On Wed, Jan 25, 2023 at 11:41:12AM -0500, Rich Salz wrote:
> > Aa for the questions of the UNIX-ness of X, it started in Athena, which as
> > I understand it was supposed to be relatively OS-agnostic distributed
> > computing? In any case, the predecessor ran on a different OS, not sure how
> > significant that is to the genesis of what would be called X or what OS it
> > "started" on.
> 
> Athena was about scaling up Unix workstations. It was started with grants
> from IBM and Digital. It was never OS-agnostic.

Well..... technically Athena was about computing in higher ed.  If you
go far back enough, at the very beginning, we used VAX 750's and IBM
PC/AT's running DOS.  As soon as the Microvax 2's and IBM PC/RT's came
in, about 2 or so years in, Project Athena switched to Unix
workstations, but in the earliest days (which would have been pre-X
Windows), Project Athena had not yet standardized on Unix or
workstations for that matter.

The VAX 750's were huge time-sharing systems that you could connect to
via VT-100's and VS-100 that were hard-wired to the VAX 750's, and
telnet from IBM PC/AT's.  The smaller clusters used PC/AT's because
they were more flexible as to which 750 you were connecting to;
otherwise, undergraduates had to go to the right terminal room in the
right part of campus to connect to the Vax 750 that you were assgined
to based on the starting character of your last name.  (And graduate
students initially didn't have access to Project Athena at all;
although if you were in EECS, LCS or the AI Lab you had access to
dedicated systems, of course.)

One of the perks for being hired as a student systems programmer back
then was that you got accounts on all of the Vax 750's, so you could
use any terminal room across campus.  :-) We then would either rlogin
to our "home" Vax 750, or we had scripts that would replicate our home
directories across the various 750's.

There was a brief, shining moment that we were standardized on
BSD-derived Unix systems, but then IBM turned down AOS (the "academic"
operating system), and we were forced to use AIX on the IBM RT's, with
all that this implied: SMIT, and other horrors.

"AIX: it *reminds* you of Unix...." was the saying at the time ---
although we tried not to say that when the IBM engineers assigned
Athena were in hearing range :-).  The one saving grace of the IBM
RT's was that they were three MIPS machines, while the Microvax's were
but a single MIPS, and that made a huge different if you were running
TeX or LaTeX.

Cheers,

						- Ted

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25 19:53     ` Theodore Ts'o
@ 2023-01-25 20:04       ` Dan Cross
  2023-01-25 20:23         ` Larry McVoy
  2023-01-27  4:49         ` Theodore Ts'o
  2023-01-26 13:17       ` Marc Donner
  1 sibling, 2 replies; 39+ messages in thread
From: Dan Cross @ 2023-01-25 20:04 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: segaloco, TUHS main list

On Wed, Jan 25, 2023 at 2:54 PM Theodore Ts'o <tytso@mit.edu> wrote:
>[snip]
> The VAX 750's were huge time-sharing systems that you could connect to
> via VT-100's and VS-100 that were hard-wired to the VAX 750's, and
> telnet from IBM PC/AT's.  The smaller clusters used PC/AT's because
> they were more flexible as to which 750 you were connecting to;
> otherwise, undergraduates had to go to the right terminal room in the
> right part of campus to connect to the Vax 750 that you were assgined
> to based on the starting character of your last name.  (And graduate
> students initially didn't have access to Project Athena at all;
> although if you were in EECS, LCS or the AI Lab you had access to
> dedicated systems, of course.)

Was this before the introduction of DECserver terminal concentrators?

>[snip]
> There was a brief, shining moment that we were standardized on
> BSD-derived Unix systems, but then IBM turned down AOS (the "academic"
> operating system), and we were forced to use AIX on the IBM RT's, with
> all that this implied: SMIT, and other horrors.

Huh, I thought that AOS ran on all versions of the RT? I know they
dropped support for it when the power-based RS/6000s came out and
replaced the RT, though.

> "AIX: it *reminds* you of Unix...." was the saying at the time ---
> although we tried not to say that when the IBM engineers assigned
> Athena were in hearing range :-).  The one saving grace of the IBM
> RT's was that they were three MIPS machines, while the Microvax's were
> but a single MIPS, and that made a huge different if you were running
> TeX or LaTeX.

The RT was a weird duck, for sure. Compared to a SPARCstation it was
absurdly slow, but I guess compared to a uVAX perhaps not so much.

        - Dan C.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25 20:04       ` Dan Cross
@ 2023-01-25 20:23         ` Larry McVoy
  2023-01-25 20:27           ` Chet Ramey
  2023-01-27  4:49         ` Theodore Ts'o
  1 sibling, 1 reply; 39+ messages in thread
From: Larry McVoy @ 2023-01-25 20:23 UTC (permalink / raw)
  To: Dan Cross; +Cc: segaloco, TUHS main list

On Wed, Jan 25, 2023 at 03:04:27PM -0500, Dan Cross wrote:
> The RT was a weird duck, for sure. Compared to a SPARCstation it was
> absurdly slow, but I guess compared to a uVAX perhaps not so much.

I think the RT predated the SPARC machines.  There were RT's running BSD
at UW-Madison when I was a grad student there (UW did something, maybe
the BSD port to RT?) and they were pretty nice.  Sun machines were still
68K, there were no SPARCs at UW-Madison at that time.  Yeah, looked it
up, they were released in 1987, we had RT machines early, perhaps before
the release in 1986 to do the port.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25 20:23         ` Larry McVoy
@ 2023-01-25 20:27           ` Chet Ramey
  0 siblings, 0 replies; 39+ messages in thread
From: Chet Ramey @ 2023-01-25 20:27 UTC (permalink / raw)
  To: Larry McVoy, Dan Cross; +Cc: segaloco, TUHS main list

On 1/25/23 3:23 PM, Larry McVoy wrote:
> On Wed, Jan 25, 2023 at 03:04:27PM -0500, Dan Cross wrote:
>> The RT was a weird duck, for sure. Compared to a SPARCstation it was
>> absurdly slow, but I guess compared to a uVAX perhaps not so much.
> 
> I think the RT predated the SPARC machines.  There were RT's running BSD
> at UW-Madison when I was a grad student there (UW did something, maybe
> the BSD port to RT?) and they were pretty nice.  

Didn't AOS use the UW BSD NFS port? I know it had NFS; we used them for a
long time and I had one in my home for years.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25 19:53     ` Theodore Ts'o
  2023-01-25 20:04       ` Dan Cross
@ 2023-01-26 13:17       ` Marc Donner
  1 sibling, 0 replies; 39+ messages in thread
From: Marc Donner @ 2023-01-26 13:17 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: TUHS main list, segaloco

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

A couple of years after Athena got going the Andrew project at CMU got
started.  That project focused primarily on early Sun workstations.  There
was some fooling around with some sort of Unix on the PC/AT, but the lack
of virtual memory support and the weakness of the networking cards for the
machine meant that we never saw them.

My memory of how X evolved is a bit confused, but there was a collaboration
between Athena and Andrew.  Each had built window systems independently.
My recollection is that Gosling, Rosenthal, and Sidebotham built the core
of the CMU one.  It introduced the separation between the display engine
(the ‘server’) and the application (the ‘client’) using an ancestor of the
X Protocol.

After a while a consolidated window system was agreed, using front end
ideas from the MIT W system and the CMU wm system and preserving the X
Protocol.  This produced a flexible architecture that allowed an
application to run anywhere and display in a window anywhere else.  It also
made networking support a must.

On Wed, Jan 25, 2023 at 2:54 PM Theodore Ts'o <tytso@mit.edu> wrote:

> On Wed, Jan 25, 2023 at 11:41:12AM -0500, Rich Salz wrote:
> > > Aa for the questions of the UNIX-ness of X, it started in Athena,
> which as
> > > I understand it was supposed to be relatively OS-agnostic distributed
> > > computing? In any case, the predecessor ran on a different OS, not
> sure how
> > > significant that is to the genesis of what would be called X or what
> OS it
> > > "started" on.
> >
> > Athena was about scaling up Unix workstations. It was started with grants
> > from IBM and Digital. It was never OS-agnostic.
>
> Well..... technically Athena was about computing in higher ed.  If you
> go far back enough, at the very beginning, we used VAX 750's and IBM
> PC/AT's running DOS.  As soon as the Microvax 2's and IBM PC/RT's came
> in, about 2 or so years in, Project Athena switched to Unix
> workstations, but in the earliest days (which would have been pre-X
> Windows), Project Athena had not yet standardized on Unix or
> workstations for that matter.
>
> The VAX 750's were huge time-sharing systems that you could connect to
> via VT-100's and VS-100 that were hard-wired to the VAX 750's, and
> telnet from IBM PC/AT's.  The smaller clusters used PC/AT's because
> they were more flexible as to which 750 you were connecting to;
> otherwise, undergraduates had to go to the right terminal room in the
> right part of campus to connect to the Vax 750 that you were assgined
> to based on the starting character of your last name.  (And graduate
> students initially didn't have access to Project Athena at all;
> although if you were in EECS, LCS or the AI Lab you had access to
> dedicated systems, of course.)
>
> One of the perks for being hired as a student systems programmer back
> then was that you got accounts on all of the Vax 750's, so you could
> use any terminal room across campus.  :-) We then would either rlogin
> to our "home" Vax 750, or we had scripts that would replicate our home
> directories across the various 750's.
>
> There was a brief, shining moment that we were standardized on
> BSD-derived Unix systems, but then IBM turned down AOS (the "academic"
> operating system), and we were forced to use AIX on the IBM RT's, with
> all that this implied: SMIT, and other horrors.
>
> "AIX: it *reminds* you of Unix...." was the saying at the time ---
> although we tried not to say that when the IBM engineers assigned
> Athena were in hearing range :-).  The one saving grace of the IBM
> RT's was that they were three MIPS machines, while the Microvax's were
> but a single MIPS, and that made a huge different if you were running
> TeX or LaTeX.
>
> Cheers,
>
>                                                 - Ted
>
-- 
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25 20:04       ` Dan Cross
  2023-01-25 20:23         ` Larry McVoy
@ 2023-01-27  4:49         ` Theodore Ts'o
  2023-01-27 18:05           ` Henry Mensch
  1 sibling, 1 reply; 39+ messages in thread
From: Theodore Ts'o @ 2023-01-27  4:49 UTC (permalink / raw)
  To: Dan Cross; +Cc: segaloco, TUHS main list

On Wed, Jan 25, 2023 at 03:04:27PM -0500, Dan Cross wrote:
> On Wed, Jan 25, 2023 at 2:54 PM Theodore Ts'o <tytso@mit.edu> wrote:
> >[snip]
> > The VAX 750's were huge time-sharing systems that you could connect to
> > via VT-100's and VS-100 that were hard-wired to the VAX 750's, and
> > telnet from IBM PC/AT's.  The smaller clusters used PC/AT's because
> > they were more flexible as to which 750 you were connecting to;
> > otherwise, undergraduates had to go to the right terminal room in the
> > right part of campus to connect to the Vax 750 that you were assgined
> > to based on the starting character of your last name.  (And graduate
> > students initially didn't have access to Project Athena at all;
> > although if you were in EECS, LCS or the AI Lab you had access to
> > dedicated systems, of course.)
> 
> Was this before the introduction of DECserver terminal concentrators?

I'm not sure; this would have been in the 1985--1987 time frame.

> >[snip]
> > There was a brief, shining moment that we were standardized on
> > BSD-derived Unix systems, but then IBM turned down AOS (the "academic"
> > operating system), and we were forced to use AIX on the IBM RT's, with
> > all that this implied: SMIT, and other horrors.
> 
> Huh, I thought that AOS ran on all versions of the RT? I know they
> dropped support for it when the power-based RS/6000s came out and
> replaced the RT, though.

Well, it perhaps would have been more accurate that IBM had decided to
that AIX was the future, and had defunded the AOS group.  While AOS
may have continued to work on the IBM RT's, the Powers That Be at IBM
had decided that AIX was the future, and when the company which is
sending you $5 million dollars a year (half in hardware and engineers'
salaries, and half in cold hard cash) wants you to switch to AIX, you
salute and reinstall AIX on all of the IBM RT's....

Later on we did get the RS/6000's, but at that point, most of us who
wanted something... that wasn't AIX, would try to get the VAXstation
3100 and later, the M38 variant.  My first staff workstation at MIT
was a VS-3100 named rt-11.mit.edu, and the VS-3100 M38 was
tsx-11.mit.edu, which became the first FTP site for Linux in North
America in 1991.  (I'm not sure how many people realized that the
primary ftp server for Linux was named after an obscure time-sharing
OS built on top of RT-11 for the PDP-11.  :-)

> The RT was a weird duck, for sure.

Well, there were the jokes that the RT was an overgrown typewriter
controller with pretensions.  :-)  And it's floating-point performance
was crap, but if you were only doing integer operations (e.g., running
TeX, running compiles), it wasn't half-bad if it wasn't running AIX.

> Compared to a SPARCstation it was
> absurdly slow, but I guess compared to a uVAX perhaps not so much.

Alas, Sun wasn't one of Project Athena's sponsors; just IBM and DEC.

It also didn't help that our contemporaneous uVax's were mostly the VS
II/RC's, with the the epoxyed backplane which limited the amount of
amount of memory that could be put in them....

       	  	      	       	      - Ted

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-27  4:49         ` Theodore Ts'o
@ 2023-01-27 18:05           ` Henry Mensch
  2023-01-27 18:24             ` Charles H Sauer (he/him)
  0 siblings, 1 reply; 39+ messages in thread
From: Henry Mensch @ 2023-01-27 18:05 UTC (permalink / raw)
  To: 'Theodore Ts'o', 'Dan Cross'
  Cc: 'segaloco', 'TUHS main list'

This was certainly true before 1986; I joined Project Athena in April of
1986 and this was quite well established by then. 

And it was no real surprise when IBM killed off AOS. AIX was already
"product" and there was no commercially installed base for RT/PC systems
worth mentioning ... (part of my job at the time was to identify and
document the differences)

-----Original Message-----
From: Theodore Ts'o <tytso@mit.edu> 
Sent: 26 January 2023 23:50
To: Dan Cross <crossd@gmail.com>
Cc: segaloco <segaloco@protonmail.com>; TUHS main list <tuhs@tuhs.org>
Subject: [TUHS] Re: Setting up an X Development Environment for Mac OS

On Wed, Jan 25, 2023 at 03:04:27PM -0500, Dan Cross wrote:
> On Wed, Jan 25, 2023 at 2:54 PM Theodore Ts'o <tytso@mit.edu> wrote:
> >[snip]
> > otherwise, undergraduates had to go to the right terminal room 
> >in the  right part of campus to connect to the Vax 750 that you were 
> >assgined  to based on the starting character of your last name. 

I'm not sure; this would have been in the 1985--1987 time frame.
-snip-
Well, it perhaps would have been more accurate that IBM had decided to that
AIX was the future, and had defunded the AOS group.




^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-27 18:05           ` Henry Mensch
@ 2023-01-27 18:24             ` Charles H Sauer (he/him)
  0 siblings, 0 replies; 39+ messages in thread
From: Charles H Sauer (he/him) @ 2023-01-27 18:24 UTC (permalink / raw)
  To: tuhs

The decision to end AOS was made sometime in 1H88 and the group of us 
that defined the "convergence" was formed. Our work must have been 
largely complete when I presented our plans at Berkeley 11/88 at a 
workshop that coincided with the Morris worm. I assume we submitted the 
Uniforum 89 paper 
(https://technologists.com/sauer/Convergence_of_AIX_and_4.3BSD.pdf) 
about then, as well.

On 1/27/2023 12:05 PM, Henry Mensch wrote:
> This was certainly true before 1986; I joined Project Athena in April of
> 1986 and this was quite well established by then.
> 
> And it was no real surprise when IBM killed off AOS. AIX was already
> "product" and there was no commercially installed base for RT/PC systems
> worth mentioning ... (part of my job at the time was to identify and
> document the differences)
> 
> -----Original Message-----
> From: Theodore Ts'o <tytso@mit.edu>
> Sent: 26 January 2023 23:50
> To: Dan Cross <crossd@gmail.com>
> Cc: segaloco <segaloco@protonmail.com>; TUHS main list <tuhs@tuhs.org>
> Subject: [TUHS] Re: Setting up an X Development Environment for Mac OS
> 
> On Wed, Jan 25, 2023 at 03:04:27PM -0500, Dan Cross wrote:
>> On Wed, Jan 25, 2023 at 2:54 PM Theodore Ts'o <tytso@mit.edu> wrote:
>>> [snip]
>>> otherwise, undergraduates had to go to the right terminal room
>>> in the  right part of campus to connect to the Vax 750 that you were
>>> assgined  to based on the starting character of your last name.
> 
> I'm not sure; this would have been in the 1985--1987 time frame.
> -snip-
> Well, it perhaps would have been more accurate that IBM had decided to that
> AIX was the future, and had defunded the AOS group.
> 
> 

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-29  0:31                 ` Kevin Bowling
@ 2023-01-29 11:07                   ` emanuel stiebler
  0 siblings, 0 replies; 39+ messages in thread
From: emanuel stiebler @ 2023-01-29 11:07 UTC (permalink / raw)
  To: Kevin Bowling, Dave Horsfall; +Cc: The Eunuchs Hysterical Society

On 2023-01-28 19:31, Kevin Bowling wrote:
> I'm not sure about 8mm tape specifically but the Exabyte drives that
> were common on 1990s UNIX systems failed a lot.
> 
> There was a large proliferation of tape technology in the 1980s and
> 1990s, many of them not great in any dimension.
> 
> DLT, LTO, and especially the "enterprise" ranges from StorageTek or
> IBM from any time period are all extremely reliable.

The problem with the 4mm and 8mm was, they had this stupid rotating head 
(heli scan?), which was a pain in the neck.
It was difficult to adjust, so you better read/wrote your tapes only
Put a lot of mechanical stress on the tape
Tape was thin, to have more capacity
After all, it was consumer stuff, ported to the wrong environment

9track, DLT work differently, that why we still have a chance to read 
them :)


^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-28 22:15               ` Dave Horsfall
@ 2023-01-29  0:31                 ` Kevin Bowling
  2023-01-29 11:07                   ` emanuel stiebler
  0 siblings, 1 reply; 39+ messages in thread
From: Kevin Bowling @ 2023-01-29  0:31 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

I'm not sure about 8mm tape specifically but the Exabyte drives that
were common on 1990s UNIX systems failed a lot.

There was a large proliferation of tape technology in the 1980s and
1990s, many of them not great in any dimension.

DLT, LTO, and especially the "enterprise" ranges from StorageTek or
IBM from any time period are all extremely reliable.

On Sat, Jan 28, 2023 at 3:16 PM Dave Horsfall <dave@horsfall.org> wrote:
>
> On Fri, 27 Jan 2023, Larry McVoy wrote:
>
> [...]
>
> > I've never seen a more fragile system than those exabyte.  By
> > comparison, the old SCSI QIC 150s, while small, were industructible, I
> > think you could have used the tapes as hammers and they'd still read.
> > Same thing for 9 track.
>
> My experience with Exabytes was different; we used "data" tapes, not the
> cheaper "video" tapes and had no problems over many years.
>
> In fact, in https://en.wikipedia.org/wiki/Data8 we see:
>
>     ``The cassettes have the same dimensions and construction as the
>       cassettes used in 8 mm video format recorders and camcorders.''
>
> In other words, they are not the same thing...
>
> -- Dave

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-27 16:10             ` Larry McVoy
@ 2023-01-28 22:15               ` Dave Horsfall
  2023-01-29  0:31                 ` Kevin Bowling
  0 siblings, 1 reply; 39+ messages in thread
From: Dave Horsfall @ 2023-01-28 22:15 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Fri, 27 Jan 2023, Larry McVoy wrote:

[...]

> I've never seen a more fragile system than those exabyte.  By 
> comparison, the old SCSI QIC 150s, while small, were industructible, I 
> think you could have used the tapes as hammers and they'd still read.  
> Same thing for 9 track.

My experience with Exabytes was different; we used "data" tapes, not the 
cheaper "video" tapes and had no problems over many years.

In fact, in https://en.wikipedia.org/wiki/Data8 we see:

    ``The cassettes have the same dimensions and construction as the
      cassettes used in 8 mm video format recorders and camcorders.''

In other words, they are not the same thing...

-- Dave

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-28  2:18               ` Larry McVoy
@ 2023-01-28  2:49                 ` Tom Perrine
  0 siblings, 0 replies; 39+ messages in thread
From: Tom Perrine @ 2023-01-28  2:49 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

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

At that time (up to 2003), every time we upgraded the tape density, or
added new archival storage, there was a "packing" job in the background.

Every time a file was retrieved and used, if it wasn't on the most dense
(newer) tape format, then the file was re-saved onto the newest,
higher-density tape.

This meant that active files were constantly copied forward onto the newer
tape formats. As all the files were copied off the lower density tapes, the
older tapes were marked "retired" and removed from the tape silos.

Then, in the background, idle tape drive time was used by a background job
that retrieved the oldest tapes, and copied the files on that tape forward.
This was enable by tape-level metadata that included the batch number and
the date that every physical tape was put into service.

Now....

Later, at Playstation we investigated the Sony ODA. If we had needed the
deep archive, we would have definitely gone with the Sony Petascale
archive. This is optical, but a disc technology that is denser and a
different formulation than Blu-Ray.

https://pro.sony/ue_US/products/optical-disc/petasite-solutions



On Fri, Jan 27, 2023 at 6:18 PM Larry McVoy <lm@mcvoy.com> wrote:

> Actually I like this fork.  I'm curious, do you know what is best practice
> for keeping bits around these days?
>
> On Fri, Jan 27, 2023 at 01:42:17PM -0800, Tom Perrine wrote:
> > A tiny bit of a fork, but...
> >
> > When I was at SDSC.EDU we did a project for the National Archives. Gotta
> > love an agency that's mission is "data for the lifetime of the
> Republic"...
> >
> > They wanted to be sure that they could still access data at least 100
> years
> > later, even assuming that no one had accessed it in that 100 year period.
> >
> > Anyway, we looked at all the options at the time (very early 2000s).
> >
> > While media lifetime was indeed understood to be critical, we
> specifically
> > called out needing to retain the software and the encryption keys. AND
> the
> > encryption algorithms!
> > At that time, media encryption was still quite new, and they hadn't
> > considered that issue. At all.
> >
> > Overall, the best, most practical approach (at that time) was to
> > periodically copy the data forward, into new media, into new
> > storage software, and decrypting with the old keys and algos, and
> > re-encrypting with new.
> >
> > Only by doing this periodically, we argued, could they really be sure of
> > being able to recover data 100+ years from now.
> >
> > Don't get me started on the degradation of early generation optical media
> > that was guaranteed for 50 years, but rusted internally within 2 years.
> >
> > And of course now there are companies that specialize in providing
> > mothballed obsolete tape and other readers.
> >
> > --tep
> >
> >
> >
> > On Fri, Jan 27, 2023 at 6:55 AM Ron Natalie <ron@ronnatalie.com> wrote:
> >
> > > When I worked in the intelligience industry, the government spent a lot
> > > of money tasking someone (I think it was Kodak) to determine the best
> > > media for archival storage.    It included traditional 6250 9 track
> > > tapes and the then-popular exabyte 8mm (which was atrociously short
> > > lived).   I pointed out that magnetic storage was probably always going
> > > to be problematic and things needed ???digital refresh??? if you really
> > > wanted to keep them.
> > >
> > >
> > > If you know the tape may be problematic when played back, there are
> > > things you can do.    I was gifted the master tapes of one of the radio
> > > shows originated at WJHU in the 70???s.   I had them sent out to a
> company
> > > who ???baked??? them, but then they also had to redo all the splices
> on them
> > > when they were played back.
> > >
>
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-27 21:42             ` Tom Perrine
@ 2023-01-28  2:18               ` Larry McVoy
  2023-01-28  2:49                 ` Tom Perrine
  0 siblings, 1 reply; 39+ messages in thread
From: Larry McVoy @ 2023-01-28  2:18 UTC (permalink / raw)
  To: Tom Perrine; +Cc: tuhs

Actually I like this fork.  I'm curious, do you know what is best practice
for keeping bits around these days?

On Fri, Jan 27, 2023 at 01:42:17PM -0800, Tom Perrine wrote:
> A tiny bit of a fork, but...
> 
> When I was at SDSC.EDU we did a project for the National Archives. Gotta
> love an agency that's mission is "data for the lifetime of the Republic"...
> 
> They wanted to be sure that they could still access data at least 100 years
> later, even assuming that no one had accessed it in that 100 year period.
> 
> Anyway, we looked at all the options at the time (very early 2000s).
> 
> While media lifetime was indeed understood to be critical, we specifically
> called out needing to retain the software and the encryption keys. AND the
> encryption algorithms!
> At that time, media encryption was still quite new, and they hadn't
> considered that issue. At all.
> 
> Overall, the best, most practical approach (at that time) was to
> periodically copy the data forward, into new media, into new
> storage software, and decrypting with the old keys and algos, and
> re-encrypting with new.
> 
> Only by doing this periodically, we argued, could they really be sure of
> being able to recover data 100+ years from now.
> 
> Don't get me started on the degradation of early generation optical media
> that was guaranteed for 50 years, but rusted internally within 2 years.
> 
> And of course now there are companies that specialize in providing
> mothballed obsolete tape and other readers.
> 
> --tep
> 
> 
> 
> On Fri, Jan 27, 2023 at 6:55 AM Ron Natalie <ron@ronnatalie.com> wrote:
> 
> > When I worked in the intelligience industry, the government spent a lot
> > of money tasking someone (I think it was Kodak) to determine the best
> > media for archival storage.    It included traditional 6250 9 track
> > tapes and the then-popular exabyte 8mm (which was atrociously short
> > lived).   I pointed out that magnetic storage was probably always going
> > to be problematic and things needed ???digital refresh??? if you really
> > wanted to keep them.
> >
> >
> > If you know the tape may be problematic when played back, there are
> > things you can do.    I was gifted the master tapes of one of the radio
> > shows originated at WJHU in the 70???s.   I had them sent out to a company
> > who ???baked??? them, but then they also had to redo all the splices on them
> > when they were played back.
> >

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-27 14:54           ` Ron Natalie
  2023-01-27 16:10             ` Larry McVoy
@ 2023-01-27 21:42             ` Tom Perrine
  2023-01-28  2:18               ` Larry McVoy
  1 sibling, 1 reply; 39+ messages in thread
From: Tom Perrine @ 2023-01-27 21:42 UTC (permalink / raw)
  To: Ron Natalie; +Cc: tuhs

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

A tiny bit of a fork, but...

When I was at SDSC.EDU we did a project for the National Archives. Gotta
love an agency that's mission is "data for the lifetime of the Republic"...

They wanted to be sure that they could still access data at least 100 years
later, even assuming that no one had accessed it in that 100 year period.

Anyway, we looked at all the options at the time (very early 2000s).

While media lifetime was indeed understood to be critical, we specifically
called out needing to retain the software and the encryption keys. AND the
encryption algorithms!
At that time, media encryption was still quite new, and they hadn't
considered that issue. At all.

Overall, the best, most practical approach (at that time) was to
periodically copy the data forward, into new media, into new
storage software, and decrypting with the old keys and algos, and
re-encrypting with new.

Only by doing this periodically, we argued, could they really be sure of
being able to recover data 100+ years from now.

Don't get me started on the degradation of early generation optical media
that was guaranteed for 50 years, but rusted internally within 2 years.

And of course now there are companies that specialize in providing
mothballed obsolete tape and other readers.

--tep



On Fri, Jan 27, 2023 at 6:55 AM Ron Natalie <ron@ronnatalie.com> wrote:

> When I worked in the intelligience industry, the government spent a lot
> of money tasking someone (I think it was Kodak) to determine the best
> media for archival storage.    It included traditional 6250 9 track
> tapes and the then-popular exabyte 8mm (which was atrociously short
> lived).   I pointed out that magnetic storage was probably always going
> to be problematic and things needed “digital refresh” if you really
> wanted to keep them.
>
>
> If you know the tape may be problematic when played back, there are
> things you can do.    I was gifted the master tapes of one of the radio
> shows originated at WJHU in the 70’s.   I had them sent out to a company
> who “baked” them, but then they also had to redo all the splices on them
> when they were played back.
>

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-27 14:54           ` Ron Natalie
@ 2023-01-27 16:10             ` Larry McVoy
  2023-01-28 22:15               ` Dave Horsfall
  2023-01-27 21:42             ` Tom Perrine
  1 sibling, 1 reply; 39+ messages in thread
From: Larry McVoy @ 2023-01-27 16:10 UTC (permalink / raw)
  To: Ron Natalie; +Cc: tuhs

On Fri, Jan 27, 2023 at 02:54:19PM +0000, Ron Natalie wrote:
> It included traditional 6250 9 track tapes and the
> then-popular exabyte 8mm (which was atrociously short lived).   

Ah, 8mm Exabyte, how I despise thee.

When I left Sun for SGI, Ken Okin graciously let me take my Sun 4/470,
that had 768MB of ram (crazy big for the time, I had that because I fixed
the VM system for big memory machines).  It also had an 8mm Exabyte and
a bunch of goodies on tape.

Wheeling that machine from my VW van into building 9 at SGI was enough
jiggling that *none* of my tapes were readable.

I've never seen a more fragile system than those exabyte.  By comparison,
the old SCSI QIC 150s, while small, were industructible, I think you
could have used the tapes as hammers and they'd still read.  Same thing
for 9 track.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-27  4:07                   ` Will Senn
  2023-01-27 14:08                     ` Chet Ramey
@ 2023-01-27 15:53                     ` Dan Cross
  1 sibling, 0 replies; 39+ messages in thread
From: Dan Cross @ 2023-01-27 15:53 UTC (permalink / raw)
  To: Will Senn; +Cc: tuhs

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

On Thu, Jan 26, 2023 at 11:08 PM Will Senn <will.senn@gmail.com> wrote:
> [snip]
> I also remember that they were bemoaning having to give up their NeXT
> boxes for racks and racks of some other machine to do equivalent work
> (at the time, I was completely clueless as to what they were talking
about).
> With decades behind, I have a clue about one workstation being oh so
> powerful and about server farms doing rendering, but I really don't know
> nothing about NeXT, it's boxes, or what I'm really wondering about - its
> relationship with unix (although I'm pretty sure there is one). I know
that
> Sun was working with them on OpenStep and OpenStep and the NeXT
> cube were predecessors to my favorite contemporary system (my Mac),
> but that's about it. So, how does NeXT fit into the unix world? And was
> it all that? I remember after talking to them that I really, really
wanted one...

As Chet mentioned, NeXTs ran NeXTStep, which was based on Mach and 4.3-ish
BSD. My sense was that they were underpowered and overpriced for the time;
they were 68k based in an era where RISC processors were dominant (or
becoming dominant) on the high end and they cost something like twice or
more that of a contemporary Macintosh while targeting roughly the same
userbase.

The software was really the interesting thing on NeXT machines. Oh the
hardware was nice enough, don't get me wrong, but compared to a SPARC or
MIPS-based workstation, I'd choose the latter every time. However, NeXTStep
was not very "Unix-y" if you were used to BSD or even System V Unixes of
the time. Things as basic as the directory structure were weirdly foreign
(though will look familiar to users of macOS now), and it used "netinfo",
which was a distributed directory service they'd built, rather than NIS or
anything remotely interoperable with the rest of the world. But the
NeXTStep user interface was very nice, and Display PostScript was
beautiful. The Objective-C foundation classes were very powerful. But it
was clear that you were meant to interact with it through the GUI, and
CLI-style interaction was an almost totally separate universe (or so it
seemed to me at the time).

One got the sense that NeXT was targeting users who had sort of outgrown
the Macintosh, but weren't ready to make the leap to a full-on workstation
on the low-end, and simultaneously trying to bring users from high-end
machines into a totally new ecosystem. But that was a really small market
and application vendors didn't jump on board: the Unix applications weren't
there, and neither were the standards from the Mac world. A few things got
ported, and that was cool, but perhaps sadly, Jobs just couldn't pull off
the magic twice, and NeXT failed. Much of the technology lives on in
macOS, though.

There's a great book about it, "Steve Jobs and the NeXT Big Thing" that's
worth a read.

        - Dan C.

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-27 13:56         ` Ralph Corderoy
@ 2023-01-27 14:54           ` Ron Natalie
  2023-01-27 16:10             ` Larry McVoy
  2023-01-27 21:42             ` Tom Perrine
  0 siblings, 2 replies; 39+ messages in thread
From: Ron Natalie @ 2023-01-27 14:54 UTC (permalink / raw)
  To: Ralph Corderoy, tuhs

When I worked in the intelligience industry, the government spent a lot 
of money tasking someone (I think it was Kodak) to determine the best 
media for archival storage.    It included traditional 6250 9 track 
tapes and the then-popular exabyte 8mm (which was atrociously short 
lived).   I pointed out that magnetic storage was probably always going 
to be problematic and things needed “digital refresh” if you really 
wanted to keep them.


If you know the tape may be problematic when played back, there are 
things you can do.    I was gifted the master tapes of one of the radio 
shows originated at WJHU in the 70’s.   I had them sent out to a company 
who “baked” them, but then they also had to redo all the splices on them 
when they were played back.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-27 14:08                     ` Chet Ramey
@ 2023-01-27 14:49                       ` Ron Natalie
  0 siblings, 0 replies; 39+ messages in thread
From: Ron Natalie @ 2023-01-27 14:49 UTC (permalink / raw)
  To: chet.ramey, Will Senn, tuhs


Having been running a University computer center we were the target 
environment for these.   Still the “optical only” drive was problematic.
By the time I actually received one (the joke was that the company was 
going to be renamed from “Next” to “Eventually”).   It did have a hard 
drive in it.
Oddly, the other thing it lacked was parity on the memory.    A big 
thing was made over the fact that the thing wasn’t exaxtly a cube in 
shape.

But it was Mach inside which meant it was fairy decent.   It was one of 
the several dozen things we ported our software to.   For some reason, 
the one I had came with a poorly digitized version of Janes All the 
World’s Aircraft.

It did have the top bar menus similar to the then MacOS environment and 
what would become the Max OSX.


^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-26 16:48           ` emanuel stiebler
  2023-01-26 21:19             ` segaloco via TUHS
@ 2023-01-27 14:17             ` Ralph Corderoy
  1 sibling, 0 replies; 39+ messages in thread
From: Ralph Corderoy @ 2023-01-27 14:17 UTC (permalink / raw)
  To: tuhs

Hi,

emanuel wrote:
> And copying the archives to newer disks, newer mail systems so it will
> hopefully survive ...

Diverging onto floppy disks, the Greaseweazle is handy for moving the
floppy-disk controller aside and getting the flux levels from the drive
for interpretation by software but sometimes that's still too high
level.

Given floppy drives often have test points on the board, they can be
used to obtain the signal from the head before the PCB has muddied its
waters.
https://scarybeastsecurity.blogspot.com/2021/05/recovering-lost-treasure-filled-floppy.html
tells of doing this with an oscilloscope allowing the recovery of some
old assembly code where the flux signal from the drive was too
corrupted.

So even if the pertinent hardware has trouble with old media, perhaps
there's still hope.

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-27  4:07                   ` Will Senn
@ 2023-01-27 14:08                     ` Chet Ramey
  2023-01-27 14:49                       ` Ron Natalie
  2023-01-27 15:53                     ` Dan Cross
  1 sibling, 1 reply; 39+ messages in thread
From: Chet Ramey @ 2023-01-27 14:08 UTC (permalink / raw)
  To: Will Senn, tuhs

On 1/26/23 11:07 PM, Will Senn wrote:
> but I really don't know nothing about NeXT, it's boxes, or what I'm really 
> wondering about - its relationship with unix (although I'm pretty sure 
> there is one). I know that Sun was working with them on OpenStep and 
> OpenStep and the NeXT cube were predecessors to my favorite contemporary 
> system (my Mac), but that's about it. So, how does NeXT fit into the unix 
> world? And was it all that? I remember after talking to them that I really, 
> really wanted one...

NeXTs were really nice boxes. The environment was basically Mach + 4.3BSD +
Display Postscript + Objective C + the libraries and frameworks that became
macOS Carbon and Cocoa + their GUI. I had one for a while, and wish I still
did for old times' sake.

NeXT was Steve Jobs's company, and Apple acquired them to make the NeXT OS
the basis of MacOS X. That is a very interesting story itself.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-26 15:28       ` [TUHS] " josh
  2023-01-26 16:07         ` [TUHS] " segaloco via TUHS
@ 2023-01-27 13:56         ` Ralph Corderoy
  2023-01-27 14:54           ` Ron Natalie
  1 sibling, 1 reply; 39+ messages in thread
From: Ralph Corderoy @ 2023-01-27 13:56 UTC (permalink / raw)
  To: tuhs

Hi josh,

> > Rob Pike wrote of magnetic tapes he had which could no longer be
> > read.  The coating had failed off IIRC.
>
> I think you’re referring to this blog post (which I’ve also previously
> struggled to find): https://commandcenter.blogspot.com/2014/08/prints.html

Thanks, that's what I was thinking of.

   ‘NASA lost a large part of the data collected by the Viking Mars
    missions because the iron oxide fell off the tapes storing the data.
    ...
    The same affliction that damaged the Viking tapes also wiped out my
    personal backup archive; I lost the only copy of my computer work
    from the 1970s.’

I first tried DuckDuckGo and Google but I don't think they associate
that site with Cmdr Pike.  I did end up there are checking my list of
RSS feeds and tediously expanded all of the right-hand indexes but
I didn't recall the photography connection and so not ‘prints’ either.

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-27  0:48                 ` segaloco via TUHS
@ 2023-01-27  4:07                   ` Will Senn
  2023-01-27 14:08                     ` Chet Ramey
  2023-01-27 15:53                     ` Dan Cross
  0 siblings, 2 replies; 39+ messages in thread
From: Will Senn @ 2023-01-27  4:07 UTC (permalink / raw)
  To: tuhs

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

On 1/26/23 6:48 PM, segaloco via TUHS wrote:
> id Software is a *perfect*​ example of the fact that you can open 
> source your stuff once it has done market rounds and still be wildly 
> successful and a household name.  It helps that John Carmack himself 
> was very principled about that sort of thing, not only contributing 
> engines as open source projects but designing them specifically to be 
> easy to modify and extend. The WAD is as responsible for the success 
> of doom as source availability methinks.
I met John Romero and American McGee back in the early 1990's as they 
were just finished with Doom II. John Carmack had some other obligation 
(sad, cuz he was the main developer), but Romero was pretty smart too - 
had plenty of insight into the space rendering mechanics and such and 
both were more than happy to share what they new, what they were working 
on, and gab about space and time :). I also remember that they were 
bemoaning having to give up their NeXT boxes for racks and racks of some 
other machine to do equivalent work (at the time, I was completely 
clueless as to what they were talking about). With decades behind, I 
have a clue about one workstation being oh so powerful and about server 
farms doing rendering, but I really don't know nothing about NeXT, it's 
boxes, or what I'm really wondering about - its relationship with unix 
(although I'm pretty sure there is one). I know that Sun was working 
with them on OpenStep and OpenStep and the NeXT cube were predecessors 
to my favorite contemporary system (my Mac), but that's about it. So, 
how does NeXT fit into the unix world? And was it all that? I remember 
after talking to them that I really, really wanted one...

Will

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-26 22:51               ` Andy Kosela
@ 2023-01-27  0:48                 ` segaloco via TUHS
  2023-01-27  4:07                   ` Will Senn
  0 siblings, 1 reply; 39+ messages in thread
From: segaloco via TUHS @ 2023-01-27  0:48 UTC (permalink / raw)
  To: Andy Kosela; +Cc: tuhs

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

id Software is a perfect​ example of the fact that you can open source your stuff once it has done market rounds and still be wildly successful and a household name. It helps that John Carmack himself was very principled about that sort of thing, not only contributing engines as open source projects but designing them specifically to be easy to modify and extend. The WAD is as responsible for the success of doom as source availability methinks.

The saving grace of it all is that disassemblers exist, so with a little knowhow and a looooot of patience, any codebase can be opened, it just may not precisely represent what the original programmer put down. It's no secret that countless significant titles have gotten this treatment already too, heck, folks have even started producing 1:1 C decompiles of some N64 titles. So at least not all is lost, but there are of course things in source code that one will never find by disassembling a binary, and especially decompiling. There is zero guarantee you've got 1:1 procedures and code, just a 1:1 binary in the end. Who knows what tools people had in their pipeline performing optimizations and such. That said, console games of the 5th gen and back are the most likely candidates for this sort of forensic preservation as they tended to be bare metal or pretty darn close to it and ubiquitous vendor libraries have leaked for many of them, so part of the reversing would just be finding the various library blobs, labeling them, and then yanking them out to just leave the engine and in-house libraries.

This is one heck of a subject drift though, trying to get better about that. Down to continue following this thread but no TUHS Cc please, at least to reply to me.

- Matt G.
------- Original Message -------
On Thursday, January 26th, 2023 at 2:51 PM, Andy Kosela <akosela@andykosela.com> wrote:

> On Thursday, January 26, 2023, segaloco via TUHS <tuhs@tuhs.org> wrote:
>
>> We benefit from a general culture of openness surrounding UNIX these days. We see no such openness from Nintendo, Sega, Sony, nor Microsoft in their video game offerings, neither current nor former, and similar for publishers and studios for the most part. Anecdotally, when SquareEnix went to reissue Final Fantasy 8, they had to rewrite it from scratch as the original PS1 source code had been lost. Apparently this is a pretty common problem plaguing efforts to roll older titles forward to modern systems, and is one of the reasons shoddy emulation seems to win out over intentional ports of anything.
>>
>> UNIX experienced the rather unique phenomenon of being able to grow legs in academia for many years before some legal types tried to put the kibosh on that. Super Mario Bros. was a closed code base from day 1 with a tight deadline and little to no reason for it to be shared outside of its own development group. The circumstances are just so wildly different. UNIX is a bit of an anomaly as far as being an iconic, ubiquitous, still appreciated design that succeeds in academic *and* commercial spheres and also has ample source code and documentation history not only available but not constantly being torpedoed by lawyers. I don't know that we'll see a willingness to open up the history of video game development like that in a timeframe that sensitive source codes and documents could still be properly preserved.
>>
>> Plus, to the defense of these studios, some algorithm or technique developed for management of game resources may still be very much relevant to modern engine designs in ways that OS code from the 70s simply wouldn't even have a place in modern design. I wouldn't be surprised if there are scene graph and asset manager algorithms and such down in, say, the Zelda 64 engine, that the big N is *still* using in comparable engines and considers a trade secret. Hard to say. But anywho, just to draw some comparisons to the preservation state of UNIX vs other technological innovations. We have decades of quality OS code to study, research, and expand upon as hackers, but we have no such wealth of real video game source codes to educate the masses on game design, especially embedded console/bare metal approaches. This is where the crossroads lies for me between my UNIX and game development interests, I would LOVE some day for there to be as accessible and quality of resources for those studying the history of game design/development as there are for those studying OS design. After all, the way I describe old games to people in a technical sense is its just a specific type of OS. That programmer had to abstract all that hardware into concepts like button triggers movement of VDP scrollplanes and emission of commands to the FM synth chip. The thing you're using is just a Dpad instead of a mouse and you're moving a silly little character instead of a window across the screen.
>
> The closest I can think of in the game industry to the open source community of Unix/Linux is Doom/Quake. Doom source code was opened in 1997 and Quake in 1999 and since then we have experienced a whole generation of programmers and artists playing with, porting and enhancing the codebase. I don't know of any other game development project that has as much longevity as those two; and all of it happened because John Carmack made the decision to open source it based on the popularity of open source Linux at the time.
>
> --Andy

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-26 21:19             ` segaloco via TUHS
@ 2023-01-26 22:51               ` Andy Kosela
  2023-01-27  0:48                 ` segaloco via TUHS
  0 siblings, 1 reply; 39+ messages in thread
From: Andy Kosela @ 2023-01-26 22:51 UTC (permalink / raw)
  To: segaloco; +Cc: tuhs

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

On Thursday, January 26, 2023, segaloco via TUHS <tuhs@tuhs.org> wrote:

> We benefit from a general culture of openness surrounding UNIX these
> days.  We see no such openness from Nintendo, Sega, Sony, nor Microsoft in
> their video game offerings, neither current nor former, and similar for
> publishers and studios for the most part.  Anecdotally, when SquareEnix
> went to reissue Final Fantasy 8, they had to rewrite it from scratch as the
> original PS1 source code had been lost.  Apparently this is a pretty common
> problem plaguing efforts to roll older titles forward to modern systems,
> and is one of the reasons shoddy emulation seems to win out over
> intentional ports of anything.
>
> UNIX experienced the rather unique phenomenon of being able to grow legs
> in academia for many years before some legal types tried to put the kibosh
> on that.  Super Mario Bros. was a closed code base from day 1 with a tight
> deadline and little to no reason for it to be shared outside of its own
> development group.  The circumstances are just so wildly different.  UNIX
> is a bit of an anomaly as far as being an iconic, ubiquitous, still
> appreciated design that succeeds in academic *and* commercial spheres and
> also has ample source code and documentation history not only available but
> not constantly being torpedoed by lawyers.  I don't know that we'll see a
> willingness to open up the history of video game development like that in a
> timeframe that sensitive source codes and documents could still be properly
> preserved.
>
> Plus, to the defense of these studios, some algorithm or technique
> developed for management of game resources may still be very much relevant
> to modern engine designs in ways that OS code from the 70s simply wouldn't
> even have a place in modern design.  I wouldn't be surprised if there are
> scene graph and asset manager algorithms and such down in, say, the Zelda
> 64 engine, that the big N is *still* using in comparable engines and
> considers a trade secret.  Hard to say.  But anywho, just to draw some
> comparisons to the preservation state of UNIX vs other technological
> innovations.  We have decades of quality OS code to study, research, and
> expand upon as hackers, but we have no such wealth of real video game
> source codes to educate the masses on game design, especially embedded
> console/bare metal approaches.  This is where the crossroads lies for me
> between my UNIX and game development interests, I would LOVE some day for
> there to be as accessible and quality of resources for those studying the
> history of game design/development as there are for those studying OS
> design.  After all, the way I describe old games to people in a technical
> sense is its just a specific type of OS.  That programmer had to abstract
> all that hardware into concepts like button triggers movement of VDP
> scrollplanes and emission of commands to the FM synth chip.  The thing
> you're using is just a Dpad instead of a mouse and you're moving a silly
> little character instead of a window across the screen.
>
>
The closest I can think of in the game industry to the open source
community of Unix/Linux is Doom/Quake. Doom source code was opened in 1997
and Quake in 1999 and since then we have experienced a whole generation of
programmers and artists playing with, porting and enhancing the codebase. I
don't know of any other game development project that has as much longevity
as those two; and all of it happened because John Carmack made the decision
to open source it based on the popularity of open source Linux at the time.

--Andy

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-26 16:48           ` emanuel stiebler
@ 2023-01-26 21:19             ` segaloco via TUHS
  2023-01-26 22:51               ` Andy Kosela
  2023-01-27 14:17             ` Ralph Corderoy
  1 sibling, 1 reply; 39+ messages in thread
From: segaloco via TUHS @ 2023-01-26 21:19 UTC (permalink / raw)
  To: emanuel stiebler; +Cc: tuhs

We benefit from a general culture of openness surrounding UNIX these days.  We see no such openness from Nintendo, Sega, Sony, nor Microsoft in their video game offerings, neither current nor former, and similar for publishers and studios for the most part.  Anecdotally, when SquareEnix went to reissue Final Fantasy 8, they had to rewrite it from scratch as the original PS1 source code had been lost.  Apparently this is a pretty common problem plaguing efforts to roll older titles forward to modern systems, and is one of the reasons shoddy emulation seems to win out over intentional ports of anything.

UNIX experienced the rather unique phenomenon of being able to grow legs in academia for many years before some legal types tried to put the kibosh on that.  Super Mario Bros. was a closed code base from day 1 with a tight deadline and little to no reason for it to be shared outside of its own development group.  The circumstances are just so wildly different.  UNIX is a bit of an anomaly as far as being an iconic, ubiquitous, still appreciated design that succeeds in academic *and* commercial spheres and also has ample source code and documentation history not only available but not constantly being torpedoed by lawyers.  I don't know that we'll see a willingness to open up the history of video game development like that in a timeframe that sensitive source codes and documents could still be properly preserved.

Plus, to the defense of these studios, some algorithm or technique developed for management of game resources may still be very much relevant to modern engine designs in ways that OS code from the 70s simply wouldn't even have a place in modern design.  I wouldn't be surprised if there are scene graph and asset manager algorithms and such down in, say, the Zelda 64 engine, that the big N is *still* using in comparable engines and considers a trade secret.  Hard to say.  But anywho, just to draw some comparisons to the preservation state of UNIX vs other technological innovations.  We have decades of quality OS code to study, research, and expand upon as hackers, but we have no such wealth of real video game source codes to educate the masses on game design, especially embedded console/bare metal approaches.  This is where the crossroads lies for me between my UNIX and game development interests, I would LOVE some day for there to be as accessible and quality of resources for those studying the history of game design/development as there are for those studying OS design.  After all, the way I describe old games to people in a technical sense is its just a specific type of OS.  That programmer had to abstract all that hardware into concepts like button triggers movement of VDP scrollplanes and emission of commands to the FM synth chip.  The thing you're using is just a Dpad instead of a mouse and you're moving a silly little character instead of a window across the screen.

- Matt G.

------- Original Message -------
On Thursday, January 26th, 2023 at 8:48 AM, emanuel stiebler <emu@e-bbes.com> wrote:


> On 2023-01-26 11:07, segaloco via TUHS wrote:
> 
> > Excellent post, thanks for the share! I think about that loss of
> > information often. Its a shame preservation hasn't been more of a
> > theme, there are probably countless iconic video games for which the
> > original source code doesn't exist anymore. If "digital archivist" was
> > more in-demand in tech companies I'd love to engage with that sort of
> > work professionally...maybe someday.
> 
> 
> But isn't it, what this group is all about?
> Collecting all the (Unix) pieces we can find, and talk about the past.
> And copying the archives to newer disks, newer mail systems so it will
> hopefully survive ...

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-26 16:07         ` [TUHS] " segaloco via TUHS
@ 2023-01-26 16:48           ` emanuel stiebler
  2023-01-26 21:19             ` segaloco via TUHS
  2023-01-27 14:17             ` Ralph Corderoy
  0 siblings, 2 replies; 39+ messages in thread
From: emanuel stiebler @ 2023-01-26 16:48 UTC (permalink / raw)
  To: segaloco, josh; +Cc: tuhs

On 2023-01-26 11:07, segaloco via TUHS wrote:
> Excellent post, thanks for the share! I think about that loss of 
> information often.  Its a shame preservation hasn't been more of a 
> theme, there are probably countless iconic video games for which the 
> original source code doesn't exist anymore.  If "digital archivist" was 
> more in-demand in tech companies I'd love to engage with that sort of 
> work professionally...maybe someday.

But isn't it, what this group is all about?
Collecting all the (Unix) pieces we can find, and talk about the past.
And copying the archives to newer disks, newer mail systems so it will 
hopefully survive ...


^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-26 15:28       ` [TUHS] " josh
@ 2023-01-26 16:07         ` segaloco via TUHS
  2023-01-26 16:48           ` emanuel stiebler
  2023-01-27 13:56         ` Ralph Corderoy
  1 sibling, 1 reply; 39+ messages in thread
From: segaloco via TUHS @ 2023-01-26 16:07 UTC (permalink / raw)
  To: josh; +Cc: tuhs

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

Excellent post, thanks for the share! I think about that loss of information often. Its a shame preservation hasn't been more of a theme, there are probably countless iconic video games for which the original source code doesn't exist anymore. If "digital archivist" was more in-demand in tech companies I'd love to engage with that sort of work professionally...maybe someday.

- Matt G.
------- Original Message -------
On Thursday, January 26th, 2023 at 7:28 AM, josh <joshnatis0@gmail.com> wrote:

> On Thursday, January 26, 2023, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
>
>> Rob Pike wrote of magnetic tapes he had which could no longer be read.
>> The coating had failed off IIRC. I tried to find the text but failed.
>> Perhaps it was on one of those Google+, Posterous, ... transient things.
>
> Hi Ralph, I think you’re referring to this blog post (which I’ve also previously struggled to find): https://commandcenter.blogspot.com/2014/08/prints.html

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-26 12:01       ` arnold
@ 2023-01-26 13:25         ` Lars Brinkhoff
  0 siblings, 0 replies; 39+ messages in thread
From: Lars Brinkhoff @ 2023-01-26 13:25 UTC (permalink / raw)
  To: arnold; +Cc: tuhs

arnold@skeeve.com wrote:
> Ralph Corderoy wrote:
>> If you know Jim, you may want to prod him to shift the data to more
>> modern media if those tapes are old.
> Amen to that.  There are tape recovery services; old X versions
> would be worth having online somewhere, for the history.

I agree, but I'm not really big on trying to pressure people to
do things.  But if someone in the Massachusetts area could offer
to help I can put you in touch.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-26 10:56     ` Ralph Corderoy
@ 2023-01-26 12:01       ` arnold
  2023-01-26 13:25         ` Lars Brinkhoff
  2023-01-26 15:28       ` [TUHS] " josh
  1 sibling, 1 reply; 39+ messages in thread
From: arnold @ 2023-01-26 12:01 UTC (permalink / raw)
  To: tuhs, ralph

Amen to that.  There are tape recovery services; old X versions
would be worth having online somewhere, for the history.

Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> Hi Lars,
>
> > Jim Gettys says he has old versions of X on tapes.
>
> If you know Jim, you may want to prod him to shift the data to more
> modern media if those tapes are old.
>
> Rob Pike wrote of magnetic tapes he had which could no longer be read.
> The coating had failed off IIRC.  I tried to find the text but failed.
> Perhaps it was on one of those Google+, Posterous, ... transient things.
>
> -- 
> Cheers, Ralph.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-26  6:30   ` Lars Brinkhoff
@ 2023-01-26 10:56     ` Ralph Corderoy
  2023-01-26 12:01       ` arnold
  2023-01-26 15:28       ` [TUHS] " josh
  0 siblings, 2 replies; 39+ messages in thread
From: Ralph Corderoy @ 2023-01-26 10:56 UTC (permalink / raw)
  To: tuhs

Hi Lars,

> Jim Gettys says he has old versions of X on tapes.

If you know Jim, you may want to prod him to shift the data to more
modern media if those tapes are old.

Rob Pike wrote of magnetic tapes he had which could no longer be read.
The coating had failed off IIRC.  I tried to find the text but failed.
Perhaps it was on one of those Google+, Posterous, ... transient things.

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25 20:38 Noel Chiappa
  2023-01-25 21:25 ` Clem Cole
  2023-01-26  6:32 ` Lars Brinkhoff
@ 2023-01-26  9:45 ` emanuel stiebler via TUHS
  2 siblings, 0 replies; 39+ messages in thread
From: emanuel stiebler via TUHS @ 2023-01-26  9:45 UTC (permalink / raw)
  To: Noel Chiappa, tuhs

On 2023-01-25 15:38, Noel Chiappa wrote:

> I have this vague memory that his version was actually written in CLU? Can
> that be correct? It would make sense, since that group was so focused on CLU
> - but maybe not, see below.

There is a copy of the email from Robert Scheifler introducing X:

https://lunduke.substack.com/p/w-the-window-system-before-x-that



^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25 20:38 Noel Chiappa
  2023-01-25 21:25 ` Clem Cole
@ 2023-01-26  6:32 ` Lars Brinkhoff
  2023-01-26  9:45 ` emanuel stiebler via TUHS
  2 siblings, 0 replies; 39+ messages in thread
From: Lars Brinkhoff @ 2023-01-26  6:32 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

Noel Chiappa writes:
> I have this vague memory that his version was actually written in CLU?

What you may remember is that X had a CLU (and Argus) interface library
before it had one for C.  It says so in Bob's announcement, of which
there is a copy of the CLU page on Wikipedia.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25 21:25 ` Clem Cole
@ 2023-01-26  6:30   ` Lars Brinkhoff
  2023-01-26 10:56     ` Ralph Corderoy
  0 siblings, 1 reply; 39+ messages in thread
From: Lars Brinkhoff @ 2023-01-26  6:30 UTC (permalink / raw)
  To: Clem Cole; +Cc: Noel Chiappa, tuhs

Clem Cole wrote:
> Noel Chiappa wrote:
> >  Do any of the really early versions of X (and W) still exist?
> Not that I have found.

Jim Gettys says he has old versions of X on tapes.

As for W, no trace that I have found.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
  2023-01-25 20:38 Noel Chiappa
@ 2023-01-25 21:25 ` Clem Cole
  2023-01-26  6:30   ` Lars Brinkhoff
  2023-01-26  6:32 ` Lars Brinkhoff
  2023-01-26  9:45 ` emanuel stiebler via TUHS
  2 siblings, 1 reply; 39+ messages in thread
From: Clem Cole @ 2023-01-25 21:25 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

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

On Wed, Jan 25, 2023 at 3:38 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>
> Do any of the really early versions of X (and W) still exist?
>
Not that I  have found.   I looked a couple a years ago.  FWIW: I would be
surprised if any of it was in CLU, because the first version of X was a
redo from synchronous W protocol to the async one Bob did.   If I remember
it correctly ... W as for the V Kernel on the Stanford (68K based) Sun
Terminal,  that  Paul Asente and Brian Reid did at Stanford (in C). The
Paul and Chris Kent at DEC (either WRL or SRC I foirget which) took it and
made it work on a VS100 and microvax. That version when to MIT via the
Athena connection and Bob rewrote the back-end creating the X from W.

Shortly after that Gettys brought the Microvax X version out to me in
Westford where, he, Jack Burness and I got it running on a 68K based
Masscomp over a weekend fairly soon after Jack his first version of his new
BITBLT primitive working - which until then we lacked (it was pretty cool
how quick it came up).

Clem
ᐧ
ᐧ

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

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [TUHS] Re: Setting up an X Development Environment for Mac OS
@ 2023-01-25 20:38 Noel Chiappa
  2023-01-25 21:25 ` Clem Cole
                   ` (2 more replies)
  0 siblings, 3 replies; 39+ messages in thread
From: Noel Chiappa @ 2023-01-25 20:38 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Lars Brinkhoff

    > It's my understanding it was started by Bob Scheifler of the CLU group.

Yes, that's correct. (Bob's office was right around the corner from me -
although I had very little knowledge of what his group was up to; I was too
busy with other things.)

I have this vague memory that his version was actually written in CLU? Can
that be correct? It would make sense, since that group was so focused on CLU
- but maybe not, see below.

X must have been done after LCS got the 750 farm (on which we ran 4.1c, to
start with) - although I don't know what kind of terminals they were using to
run X on - we didn't have any bit-mapped displays on them, I'm pretty sure.
Although maybe it was later, once Micro-Vaxes appeared?

I have this vague memory that it was based (perhaps only in design, not code
re-use) on a window system done at Stanford {looks}; yes, W (hence 'X'):

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

The X paper listed there:

  https://dl.acm.org/doi/pdf/10.1145/22949.24053

doesn't say anything about the implementation, so maybe that vague
memory/assumption that I had that it was originally written in CLU is wrong.
Liskov's 'History of CLU' paper, which lists things done in CLU, doesn't
mention it, so I must have been confused?

Do any of the really early versions of X (and W) still exist?

	Noel

^ permalink raw reply	[flat|nested] 39+ messages in thread

end of thread, other threads:[~2023-01-29 11:08 UTC | newest]

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-25  1:46 [TUHS] Setting up an X Development Environment for Mac OS Will Senn
2023-01-25  7:45 ` [TUHS] " segaloco via TUHS
2023-01-25  8:00   ` Lars Brinkhoff
2023-01-25 16:41   ` Rich Salz
2023-01-25 19:53     ` Theodore Ts'o
2023-01-25 20:04       ` Dan Cross
2023-01-25 20:23         ` Larry McVoy
2023-01-25 20:27           ` Chet Ramey
2023-01-27  4:49         ` Theodore Ts'o
2023-01-27 18:05           ` Henry Mensch
2023-01-27 18:24             ` Charles H Sauer (he/him)
2023-01-26 13:17       ` Marc Donner
2023-01-25 20:38 Noel Chiappa
2023-01-25 21:25 ` Clem Cole
2023-01-26  6:30   ` Lars Brinkhoff
2023-01-26 10:56     ` Ralph Corderoy
2023-01-26 12:01       ` arnold
2023-01-26 13:25         ` Lars Brinkhoff
2023-01-26 15:28       ` [TUHS] " josh
2023-01-26 16:07         ` [TUHS] " segaloco via TUHS
2023-01-26 16:48           ` emanuel stiebler
2023-01-26 21:19             ` segaloco via TUHS
2023-01-26 22:51               ` Andy Kosela
2023-01-27  0:48                 ` segaloco via TUHS
2023-01-27  4:07                   ` Will Senn
2023-01-27 14:08                     ` Chet Ramey
2023-01-27 14:49                       ` Ron Natalie
2023-01-27 15:53                     ` Dan Cross
2023-01-27 14:17             ` Ralph Corderoy
2023-01-27 13:56         ` Ralph Corderoy
2023-01-27 14:54           ` Ron Natalie
2023-01-27 16:10             ` Larry McVoy
2023-01-28 22:15               ` Dave Horsfall
2023-01-29  0:31                 ` Kevin Bowling
2023-01-29 11:07                   ` emanuel stiebler
2023-01-27 21:42             ` Tom Perrine
2023-01-28  2:18               ` Larry McVoy
2023-01-28  2:49                 ` Tom Perrine
2023-01-26  6:32 ` Lars Brinkhoff
2023-01-26  9:45 ` emanuel stiebler via TUHS

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).