[TUHS] Re: Setting up an X Development Environment for Mac OS

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Noel Chiappa]

    > 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

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Clem Cole]

[-- 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 --]

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Lars Brinkhoff]

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.

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Ralph Corderoy]

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.

[TUHS] Re: Setting up an X Development Environment for Mac OS

[arnold]

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.

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Lars Brinkhoff]

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.

[TUHS] Setting up an X Development Environment for Mac OS

[josh]

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

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: 754 bytes --]

[TUHS] Re: Setting up an X Development Environment for Mac OS

[segaloco via 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 --]

[TUHS] Re: Setting up an X Development Environment for Mac OS

[emanuel stiebler]

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 ...

[TUHS] Re: Setting up an X Development Environment for Mac OS

[segaloco via 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 ...

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Andy Kosela]

[-- 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 --]

[TUHS] Re: Setting up an X Development Environment for Mac OS

[segaloco via 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 --]

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Will Senn]

[-- 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 --]

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Chet Ramey]

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/

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Ron Natalie]

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.

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Dan Cross]

[-- 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 --]

[TUHS] NEXTSTEP 486 [was Re: Setting up an X Development Environment for Mac OS

[Charles H Sauer (he/him)]

NEXTSTEP was (is?) interesting for many reasons IMO, especially what 
Berners-Lee did at CERN, and can still run today on appropriate 486 
machines.

I was in the thick of getting NEXTSTEP on 486. See 
https://notes.technologists.com/notes/2019/07/01/koko-exploring-nextstep-486/ 
and 
https://notes.technologists.com/notes/2019/07/01/koko-reviving-timbls-worldwideweb-browser/

Though our JAWS machine was Jobs' preferred demo machine for NEXTSTEP 
486, NEXT supported a surprising variety of machines and peripherals by 
the 3.3 release. I have NEXTSTEP 486 (and other old OS) running on a 
couple of more popular Dell 486 machines as well as JAWS 
(https://notes.technologists.com/notes/2019/09/26/koko-welcome-to-eight-jurassic-o-s-on-1992-dell-486d-50/). 
There are probably many other early 90s 486 machines that could be made 
to run NEXTSTEP 486.

Charlie


On 1/27/2023 9:53 AM, Dan Cross wrote:
> On Thu, Jan 26, 2023 at 11:08 PM Will Senn <will.senn@gmail.com 
> <mailto: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.
> 

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

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Ralph Corderoy]

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.

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Ralph Corderoy]

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.

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Ron Natalie]

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.

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Larry McVoy]

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.

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Dave Horsfall]

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

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Kevin Bowling]

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

[TUHS] Re: Setting up an X Development Environment for Mac OS

[emanuel stiebler]

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 :)

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Tom Perrine]

[-- 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 --]

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Larry McVoy]

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

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Tom Perrine]

[-- 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 --]

[TUHS] Re: Setting up an X Development Environment for Mac OS

[Lars Brinkhoff]

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.

[TUHS] Re: Setting up an X Development Environment for Mac OS

[emanuel stiebler via 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