[TUHS] lost ports

[TUHS] lost ports

[ron minnich]

So there are a few ports I know of that I wonder if they ever made it back
into that great github repo.I don't think they did.

harris
gould
That weird BBN 20-bit machine
   (20 bits? true story: 5 4-bit modules fit in a 19" rack. So 20 bits)
Alpha port (Tru64)
Precision Architecture
Unix port to Cray vector machines

others? What's the list of "lost machines" look like? Would companies
consider a donation, do you think?

If that Cray port is of any interest I have a thread I can push on maybe.

but another true story: I visited DEC in 2000 or so, as LANL was about to
spend about $120M on an Alpha system. The question came up about the SRM
firmware for Alpha. As it was described to me, it was written in BLISS and
the only machine left that could build it was an 11/750, "somewhere in the
basement, man, we haven't turned that thing on in years". I suspect there's
a lot of these containing oxide oersteds of interest.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170104/74fb2664/attachment.html>

[TUHS] lost ports

[Ron Natalie]

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

I worked a lot on the Gould SEL machines.    I believe they copted George Goble from Purdue and some of his gang to do a lot of the initial OS work as the machines were dual processors and George had done the multiprocessor kernel for his “dual VAX” hack.

 

We met with the project leading vice president, Jim Clark when they were planning this and really drove them torwards a BSD based kernel.     His eyes lit up when we told him of Doug Gwyn’s SV on BSD dist which seaeled the deal.    Amusingly, the SEL UNIX didn’t put a memory page at location zero by default.    This should have been fine.    In the PDP-11 kernel, location zero usually held the first few instructions of the program (notably a setd instruction and a few others that would cause printf(“%s”, 0) to print p&P6).   The VAX BSD kernel put a zero at location zero which allowed all sorts of bugs to hide.       We didn’t really mind the SEL behavior until we found a few programs that we didn’t have source code for crashing (notably Oracle).    We had to put a hack in that if the a.out had a non-zero value in one of the unused fields it would put it in to “braindamaged VAX compatilibilty mode” mapping a zero at zero.    This allowed us to poke the afflicted binaries.    

 

Years later a friend of mine was saying…here’s something you don’t see every day…a black computer company VP.   I pointed out that I had worked with Jim Clark at Gould so there must be at least two.    Turns out the article he was reading was about Jim joining AT&T.   He’s still around somewhere (he’s on the board of the EAA right now).   He might be a good guy to invite to the list.

 

The BBN C machines were indeed potentially 20 bits.   They were designed to be a generic hardware emulator, specifically to replace the Honeywell 516s that were being used for IMPS and TIPS at the time.    They then sold someone (DARPA I suspect) the idea that they could write an instrution set that would be ideal for the C language and UNIX.     I’m pretty sure that it was only doing 16 bit operations rather than 20.   If I recall properly the systems were kind of klunky in practice.   The Army had a few of them around.    I never heard the 5 4-bit modules fit into a rack.  The thing was pretty  monolithic looking (about 3’ of 19” rack) and not modular at all.

 

I did kernel work on the PA for HP also worked on their X server (did a few other X servers over the years).

 

The hard part would be finding anybody from these companies who could even remember they made computers let alone had  UNIX software.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170104/66dc58f6/attachment-0001.html>

[TUHS] lost ports

[Larry McVoy]

I worked on the ETA-10 (CDC spinoff, Neil Lincoln was the architect):

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

No idea if the code is still around, I would guess it's lost.  Be fun
if it showed up, I wrote a kmem "driver" so I could get my own version
of ps(1) to run.  As I recall, it was an ioctl that just fed me back
everything I needed, it wasn't a kmem driver at all, this was my first
real job after grad school and I had no idea how to write a driver :)

On Wed, Jan 04, 2017 at 09:24:37PM +0000, ron minnich wrote:
> So there are a few ports I know of that I wonder if they ever made it back
> into that great github repo.I don't think they did.
> 
> harris
> gould
> That weird BBN 20-bit machine
>    (20 bits? true story: 5 4-bit modules fit in a 19" rack. So 20 bits)
> Alpha port (Tru64)
> Precision Architecture
> Unix port to Cray vector machines
> 
> others? What's the list of "lost machines" look like? Would companies
> consider a donation, do you think?
> 
> If that Cray port is of any interest I have a thread I can push on maybe.
> 
> but another true story: I visited DEC in 2000 or so, as LANL was about to
> spend about $120M on an Alpha system. The question came up about the SRM
> firmware for Alpha. As it was described to me, it was written in BLISS and
> the only machine left that could build it was an 11/750, "somewhere in the
> basement, man, we haven't turned that thing on in years". I suspect there's
> a lot of these containing oxide oersteds of interest.
> 
> ron

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

[TUHS] lost ports

[Robert Swierczek]

I have run into interesting Unix code on the bitsavers site under
bits/Unisoft and bits/SGI.  In addition, archive.org has some
interesting snapshots as well.  I have always assumed they may be
tainted in some way that discourages further exposure?  Do these sites
have some kind of "library" status that provides cover to host these
artifacts?

[TUHS] lost ports

[Dan Cross]

Along those lines....

I once heard about a paper that was presented at some conference titled
something along the lines of, "My Goodness: It Still Runs?!". The topic was
some sort of early version of Unix running on some ancient piece of
hardware doing some sort of industrial control. When I heard about it, a
notable part of the paper was a mention that it was believed they had
removed all bugs from the implementation.

Not quite a lost version of Unix, but almost a lost+found version. Has
anyone else heard of this paper? Perhaps it is apocryphal? I've always
wanted to read it, but never found a copy "in the wild."

        - Dan C.


On Wed, Jan 4, 2017 at 4:24 PM, ron minnich <rminnich at gmail.com> wrote:

> So there are a few ports I know of that I wonder if they ever made it back
> into that great github repo.I don't think they did.
>
> harris
> gould
> That weird BBN 20-bit machine
>    (20 bits? true story: 5 4-bit modules fit in a 19" rack. So 20 bits)
> Alpha port (Tru64)
> Precision Architecture
> Unix port to Cray vector machines
>
> others? What's the list of "lost machines" look like? Would companies
> consider a donation, do you think?
>
> If that Cray port is of any interest I have a thread I can push on maybe.
>
> but another true story: I visited DEC in 2000 or so, as LANL was about to
> spend about $120M on an Alpha system. The question came up about the SRM
> firmware for Alpha. As it was described to me, it was written in BLISS and
> the only machine left that could build it was an 11/750, "somewhere in the
> basement, man, we haven't turned that thing on in years". I suspect there's
> a lot of these containing oxide oersteds of interest.
>
> ron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170104/a977d5b6/attachment.html>

[TUHS] lost ports

[Larry McVoy]

On Wed, Jan 04, 2017 at 01:58:39PM -0800, Larry McVoy wrote:
> I worked on the ETA-10 (CDC spinoff, Neil Lincoln was the architect):
> 
> https://en.wikipedia.org/wiki/ETA10
> 
> No idea if the code is still around, I would guess it's lost.  Be fun
> if it showed up, I wrote a kmem "driver" so I could get my own version
> of ps(1) to run.  As I recall, it was an ioctl that just fed me back
> everything I needed, it wasn't a kmem driver at all, this was my first
> real job after grad school and I had no idea how to write a driver :)

I am apparently wrong, this has made be go through my notes.  I actually
wrote some drivers for the ETA project (I'm sure by copying other ones
and hacking them).

The ETA had local memory and then a big pool of shared memory but it 
was bcopy() shared.  I wrote the driver that let you access the shared
memory.

The proc/kmem thing was driven by the fact that nlist was slow.  So I
wrote a driver that gave you the process table.  Pretty simple.

There was something called an Ibis disk, I didn't do the controller
part, I did the Unix part that talked to the controller.  My notes say
"I wrote the Unix side of the driver which involved mapping the IOU into
shared memory.  Both interrupt and polled versions were used, currently
the polled is used due to interrupt problems with I/O channels."

All that said, I'm not a driver person, I suck at that.

[TUHS] lost ports

[Clem Cole]

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

​below...​

On Wed, Jan 4, 2017 at 4:24 PM, ron minnich <rminnich at gmail.com> wrote:

> but another true story: I visited DEC in 2000 or so, as LANL was about to
> spend about $120M on an Alpha system. The question came up about the SRM
> firmware for Alpha. As it was described to me, it was written in BLISS and
> the only machine left that could build it was an 11/750, "somewhere in the
> basement, man, we haven't turned that thing on in years". I suspect there's
> a lot of these containing oxide oersteds of interest.


​Cute story but not true [and I was @ DEC working Alpha at that time].
Some facts:

A.) The SRM firmware was in C primary and Assembler and used >>UNIX<< tools
not VMS tools for development
B.) The GEM compiler (which still exists and still being developed by VMSI)
had front ends for at least (which I remember):   BLISS, C, PL/1, Pascal,
ADA, FORTRAN​, Cobol, RPG and a few others (I'll try to ask if I see any of
the old GEM guys in the Cafe' in the next few hours - they are dying off
BTW - but that's a different story).
C.) The GEM compiler has backends for,  Vax, Galaxy, MIPS, Alpha, x86
(32bit), ia64, INTEL*64 (post DEC/Compaq/HP) and I believe also ARM (I'll
need to ask if the VMSI folks come to lunch on Friday).
D.) Alpha's ran UNIX before they ran VMS BTW.  The HW debug was all UNIX.

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

[TUHS] lost ports

[Derek Fawcus]

On Wed, Jan 04, 2017 at 09:24:37PM +0000, ron minnich wrote:
> So there are a few ports I know of that I wonder if they ever made it back
> into that great github repo.I don't think they did.
> 
> gould

The Gould powernode was my first experience of unix at uni.
They must have had a source licence,  as in grubbing around in the filesystem,
I eventually stumbled across source code - certainly for user space,
I can't really recall if they had kernel stuff as well.

Reading the code for ed, and seeing the internal implementation of regex's was
an eye opener.

DF

[TUHS] lost ports

[Clem Cole]

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

​I also left out....

E.) GEM tools ran on VMS, Ultrix, Mica, OSF/1, Tru64, Mac OSx, NT/4 and
later Windows version up too and now Win10​

And I was just reminded that there was a 68K back-end done for it also that
terminal folks used, although I'm not sure I ever saw it.

Ron - for whatever its worth, the whole BLISS vs C is different history
both outside and inside of DEC [which some of lived and I'll not repeat it
here].   But it is sadly miss represented.   I'm a C programmer and while I
learned BLISS before C, I certainly prefer C to BLISS as do many of my
peers - even heavy, heavy BLISS hackers I know.

You should know that the compiler team was definitely BLISS based, as was
the VMS group, but once Streams I/O was added to VMS and the C compiler
introduced, most VMS customers left RMS I/O; while continuing to use
FORTRAN as the primary VMS end-user language, BLISS was less so, C and
Pascal quickly became more popular.   Even at DEC, C took off, particularly
in the HW teams if for no other reason than you could hire C programmers
from Universities and you had to teach them BLISS.

Clem

On Thu, Jan 5, 2017 at 11:01 AM, Clem Cole <clemc at ccc.com> wrote:

> ​below...​
>
> On Wed, Jan 4, 2017 at 4:24 PM, ron minnich <rminnich at gmail.com> wrote:
>
>> but another true story: I visited DEC in 2000 or so, as LANL was about to
>> spend about $120M on an Alpha system. The question came up about the SRM
>> firmware for Alpha. As it was described to me, it was written in BLISS and
>> the only machine left that could build it was an 11/750, "somewhere in the
>> basement, man, we haven't turned that thing on in years". I suspect there's
>> a lot of these containing oxide oersteds of interest.
>
>
> ​Cute story but not true [and I was @ DEC working Alpha at that time].
> Some facts:
>
> A.) The SRM firmware was in C primary and Assembler and used >>UNIX<<
> tools not VMS tools for development
> B.) The GEM compiler (which still exists and still being developed by
> VMSI) had front ends for at least (which I remember):   BLISS, C, PL/1,
> Pascal, ADA, FORTRAN​, Cobol, RPG and a few others (I'll try to ask if I
> see any of the old GEM guys in the Cafe' in the next few hours - they are
> dying off BTW - but that's a different story).
> C.) The GEM compiler has backends for,  Vax, Galaxy, MIPS, Alpha, x86
> (32bit), ia64, INTEL*64 (post DEC/Compaq/HP) and I believe also ARM (I'll
> need to ask if the VMSI folks come to lunch on Friday).
> D.) Alpha's ran UNIX before they ran VMS BTW.  The HW debug was all UNIX.
>
> Clem
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170105/1b29c68f/attachment.html>

[TUHS] lost ports

[ron minnich]

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

On Thu, Jan 5, 2017 at 8:02 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> ​Cute story but not true [and I was @ DEC working Alpha at that time].
> Some facts:
>

Clem, thanks for the correction. This leaves me wondering why I was so
naive as to believe that fable from those guys we visited ...

I suspect they did not know or were just lying to me, since the question
came up in the context of LInuxBIOS for the 4-socket system (2048 of them
were used in ASCI Q) and I doubt they wanted to hear about non-DEC firmware
on that system.

The SRM was a huge pain point on that machine and we hoped to replace it
with something we could live with, but it was not to be.

We did get LinuxBIOS on the 1-socket pizza box thanks to Eric Biederman and
Linux NetworX, which we used to build a 128-node LinuxBIOS cluster.
LinuxBIOS included a PALcode implementation.

Which leads to a question ... Jon Hall used to tell me that DEC used SRM in
general and PALcode in particular as competitive leverage with customers
(i.e. DEC-based Alpha systems always had the latest SRM and PALcode, and
non-DEC-based Alpha systems were always a few revs behind).

Note this implies DEC as a systems vendor was competing with DEC Alpha chip
customers who were systems vendors, which was a situation we've seen in
practice with many vendors that sold chips and motherboards.

Anyway, the question: with LinuxBIOS, we shipped a GPL-ed PALcode
implementation. It was pretty dumb, it just did 1:1 virt to phys mapping
for example, but it worked. I've always believed that was the only open
source or at least GPL'ed PALcode out there -- can you tell me if I got
this right?

Thanks, it's always good to read your histories ...

sorry this is not strictly a Unix history question but I've always wondered.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170105/22a4cc5e/attachment.html>

[TUHS] lost ports

[Pierre DAVID]

On Thu, Jan 05, 2017 at 04:15:28PM +0000, Derek Fawcus wrote:
>
>The Gould powernode was my first experience of unix at uni.
>

A Gould powernode (hostname = gouldorak) was sitting in the Computing
facility at my first work, with a VAX. The Gould load average was very
impressive, many huge pig processes (chemical simulations) were running
all time, but this machine crashed many times a week, system engineers
very busy at this time (fsck, restore, etc.).

The day a new Cray was installed, the main pig processes were migrated
to this new machine. From this day, the load average of the Gould, which
was still running, gone down. And the beast never crashed again. And
system engineers were no longer busy with the Gould.

Therefore, many chemists were confusing causality: they said that without
system engineer, a computer works better.

Pierre

[TUHS] lost ports

[Clem Cole]

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

On Thu, Jan 5, 2017 at 12:23 PM, ron minnich <rminnich at gmail.com> wrote:

> Anyway, the question: with LinuxBIOS, we shipped a GPL-ed PALcode
> implementation. It was pretty dumb, it just did 1:1 virt to phys mapping
> for example, but it worked. I've always believed that was the only open
> source or at least GPL'ed PALcode out there -- can you tell me if I got
> this right?


I have no reason to believe it is otherwise - i.e. I have no knowledge of
anything else.   Your comment about PALcode being used as leverage, I never
saw that in practice and I worked with a lot of external folks.     I think
it was more of a delta-T between the time DEC engineering released the code
and DEC-Semi got it to the field and the integrators into their systems.

I don't think DEC systems sales tried to compete with the DEC-Semi
customers, although in practice​ I'm sure they were not very good at being
to have it both ways and certainly made mistakes.   Maurice Marks was the
lead techie @ DEC Semi in those days, and a colleague I used to see fairly
often then.   I know Maurice would have screamed pretty loud if he saw the
system side of DEC mucking up his business and I think G2-Bob would have
swatted folks if they had - he wanted revenue anyway he could get it.   As
I think you know my last DEC projects was the 1K Alpha were we spliced an
EV6 into a $799 AMD based system.   The DEC guys were the ones that hated
it (Compaq actually liked it because Dell could not do it).  Anyway,
Maurice and I were shaking our heads on that one.

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

[TUHS] lost ports

[ron minnich]

On Thu, Jan 5, 2017 at 11:09 AM Clem Cole <clemc at ccc.com> wrote:

>
> As I think you know my last DEC projects was the 1K Alpha were we spliced
> an EV6 into a $799 AMD based system.
>

That was an awesome project. I assume it ran Tru64? How did it work out
saleswise? It always seemed to me you had done a great trick there of
leveraging commodity mainboard economics.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170105/94565b81/attachment-0001.html>

[TUHS] lost ports

[Clem Cole]

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

On Thu, Jan 5, 2017 at 2:16 PM, ron minnich <rminnich at gmail.com> wrote:

> That was an awesome project. I assume it ran Tru64?

​FreeBSD and Tru64 using an non-standard (Adaptec SCSI controller) tested
not 100% completed (I ran it on my desk for a bit, but there was some rough
edges).  Linux was proposed and should have been fairly easy. Same for
NT/Alpha.  It never ran VMS due to a motherboard issue with DMA and the
specific disk controller VMS used [qLogic ISP], but folks could have
written a new driver for it if need be.​   VMS could use disks on an
Adaptec controller but could not boot from one, which both UNIX and Windows
could; although officially Tru64 did not support the Adaptec in the SPD
(because they could not support fail-over in TruClusters].




> How did it work out saleswise?

​Never sold - killed by a VP who I will leave nameless.  All I'll say is
that he was claiming that you could not make an Alpha for under $5K.   From
my NCR days, I knew the guy that was running consumer PC's at Compaq.  And
after the merger, I told Craig that the EV6 and K8 were electrical twins
(not mechanical) - as DEC had licensed the Alpha memory system to AMD.  He
got excited and an adaptor board was built to deal with the mechanical
issues.

At the time, the differential cost between K8 and EV6 was a little less
than $200.  Craig has used at 150W over supply, all plastic case etc...
System was sold via Radio Shack at the time.   It was all about low cost.
BTW:  I still have the motherboard we used in my basement and the EV6 on my
desk @ Intel.



> It always seemed to me you had done a great trick there of leveraging
> commodity mainboard economics.

​Yes, but we had "raped the virgin mother" in the eyes of the DEC big iron
folks because we made an Alpha on 16% gross margins not 43% like
TurboLaser.​  (i.e. the DEC side not the Compaq side killed it).   The
point is at 43% gross margins and built like a DEC system (steel cases,
400W power supply) et al, it did come to $5K; if you built it like Compaq
and used Compaq margins; you could break $1K.

When I got shot down after I presented to the sr folks what we did, I
returned the call from a start-up the next day.  A month later,  was VP of
Engineering at Paceline.

BTW: I think that I still have the business proposal PPT somewhere in my
archives (I ran into a couple of summer ago).  Like bitsavers, there needs
to be an archive of cool ideas that companies never had the guts to follow
thru on.

Oh well.

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

[TUHS] lost ports

[Lawrence Stewart]

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

I left Digital in 1994, so I don’t know much about the later evolution of the Alphaservers, but 1998 would have been about right for en EV-56 (EV-5 shrink) or EV-6.  There’s a Wikipedia article about all the different systems but most of the dates are missing.

The white label parts are all PAL22V10-15s.  The 8 square chips are cache SRAMS, and most the the SOIC jellybeans are bus transceivers to connect the CPU to RAM and I/O.  The PC derived stuff is in the back corner.  There are 16 DIMM slots to make two ranks of 54 bit RAM out of 8-bit DIMMs.  We usually ran with a SCSI card, an ethernet, and an 8514 graphics card plugged into the riser.

-L

> On 2017, Jan 5, at 5:55 PM, ron minnich <rminnich at gmail.com> wrote:
> 
> What version of this would I have bought ca. 1998? I had 16 of some kind of Alpha nodes in AMD sockets, interconnected with SCI for encoding videos. I ended up writing and releasing what I think were the first open source drivers for SCI -- it took a long time to get Dolphin to let me release them.
> 
> The DIPs with white labels -- are those PALs or somethin? Or are the labels just to cover up part names :-)
> 
> On Thu, Jan 5, 2017 at 2:39 PM Lawrence Stewart <lstewart2 at gmail.com <mailto:lstewart2 at gmail.com>> wrote:
> Alphas in PC boxes!  I dug around in the basement and found my Beta (photo attached).
> 
> This was from 1992 or 1993 I think.  This is an EV-3 or EV-4 in a low profile PC box using pc peripherals.  Dave Conroy designed the hardware, I did the console ROMS (BIOS equivalent) and X server, and Tom Levergood ported OSF-1.  A joint project of DEC Semiconductor Engineering and the DEC Cambridge Research Lab. I think about 20 were built, and the idea kickstarted a line of low end Alphaservers.
> 
> This was a typical Conroy minimalist design, crunching the off-chip caches, PC junk I/O, ISA bus, and 64 MBytes of RAM into this little space.  I think one gate array would replace about half of the chips.
> 
> -L
> 
> 
> <IMG_0939.JPG><IMG_0939.JPG>

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

[TUHS] lost ports

[Rudi Blom]

>Date: Wed, 4 Jan 2017 16:41:07 -0500
>From: "Ron Natalie" <ron at ronnatalie.com>
>To: "'ron minnich'" <rminnich at gmail.com>,       <tuhs at minnie.tuhs.org>
>Subject: Re: [TUHS] lost ports
>Message-ID: <01c001d266d3$42294820$c67bd860$@ronnatalie.com>
>Content-Type: text/plain; charset="utf-8"
...
>I did kernel work on the PA for HP also worked on their X server (did a few other X server >over the years).

>The hard part would be finding anybody from these companies who could even remember
>they made computers let alone had  UNIX software.

I worked for the computer division in Philips Electronics, DEC,
Compaq, HP, HPE and still remember some of it :-)

I wasn't involved in OS development, but in testing, turnover to
National Sales Organisations, etc. Even now at some customer side I
still have a few aDEC400xP servers from 1992 running SCO UNIX 3.2V4.2
(last update 1999). Also a few AlphaServers with Digital UNIX, Tru64;
finally some Itanium servers with HP-UX 11.23/11.31.

Especially the big/small endian issue gave our customer (and therefore
myself) a few headaches. Imagine getting a chunk of shared memory and
casting pointers assuming the 'system' takes care of alignment. Big
surprise for the customer moving from Tru64 to HP-UX.