[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Arno Griffioen]

Hi!

Some of the stories on here reminded me of the fact that there's also likely 
a whole boat-load of UNIX ports/variants in the past that were never released 
to customers or outside certain companies.

Not talking about UNIX versions that have become obsolete or which have
vanished by now like IRIX or the original Apple A/UX (now *that* was an 
interesting oddball though..) and such, but the ones that either died or 
failed or got cancelled during the product development process or were never 
intended to be released to the outside ar all.

Personally I came across one during some UNIX consultancy work at Commodore 
during the time that they were working on bringing out an SVR4 release for the 
Amiga (which they actually sold for some time)

Side-note.. Interestingly enough according to my contacts at that time inside 
CBM it was based on the much cheaper to license 3B2 SVR4 codebase and not the 
M68k codebase which explained some of the oddities and lack of M68k ABI 
compliance of the Amiga SVR4 release.. 

However.. 

It turned out that they had been running an SVRIII port on much older Amiga 
2000's with 68020 cards for some of their internal corporate networking and 
email, UUCP, etc. and was called 'AMIX' internally. But as far as I know it 
was never released to the public or external customers.

It was a fairly 'plain jane' SVRIII port with little specific 'Amiga' hardware 
bits supported but otherwise quite complete and pretty stable.

Worked quite well in the 4MB DRAM available on these cards. The later SVR4
didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!) 
16MB.

It was known 'outside' that something like this existed as the boot ROM's on 
the 68020 card had an 'AMIX' option but outside CBM few people really knew 
much about it.

It may have been used at the University of Lowell as they developed a TI34010 
based card that may already have had some support in this release.

Still..

This does make me wonder.. Does anyone else know of these kinds of special 
'snowflake' UNIX versions that never got out at various companies/insitutes?
(and can talk about it without violating a whole stack of NDA's ;) )

No special reason.. Just idle curiosity :)

Likely all these are gone forever anyway as prototypes and small run production 
devices and related software tends to get destroyed when companies go bust or 
get aquired.

							Bye, Arno.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Larry McVoy]

On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno Griffioen wrote:
> Worked quite well in the 4MB DRAM available on these cards. The later SVR4
> didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!) 
> 16MB.

Back in the days of 4MB SPARC machines (and 68K machines) we joked
that EMACS stood for Eight Megs And Constantly Swapping.  David
Rosenthal, a Sun DE, was known for running emacs on the bitmapped
console in terminal mode so as to not let X11 or NeWS eat up ram.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Steve Nickolas]

On Sat, 25 Feb 2017, Larry McVoy wrote:

> On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno Griffioen wrote:
>> Worked quite well in the 4MB DRAM available on these cards. The later SVR4
>> didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!)
>> 16MB.
>
> Back in the days of 4MB SPARC machines (and 68K machines) we joked
> that EMACS stood for Eight Megs And Constantly Swapping.  David
> Rosenthal, a Sun DE, was known for running emacs on the bitmapped
> console in terminal mode so as to not let X11 or NeWS eat up ram.
>

From that nickname I came up with "Enough Memory A Concept Strange", as 8 
MB was no longer a lot of memory.

Disclosure - never was an EMACS person, or a vi person, pico was and nano 
is more my cup of tea.  That said, I can fumble my way around vi if I 
absolutely must.

-uso.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Joerg Schilling]

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

Steve Nickolas <usotsuki at buric.co> wrote:

> On Sat, 25 Feb 2017, Larry McVoy wrote:
> > Back in the days of 4MB SPARC machines (and 68K machines) we joked
> > that EMACS stood for Eight Megs And Constantly Swapping.  David
> > Rosenthal, a Sun DE, was known for running emacs on the bitmapped
> > console in terminal mode so as to not let X11 or NeWS eat up ram.
> >
>
> From that nickname I came up with "Enough Memory A Concept Strange", as 8 
> MB was no longer a lot of memory.

On my Sun-2/50 at home and my 3-50 at work, I edited in console mode when I was 
working on drivers - just because launching Sunview did take too much time and 
I needed to reboot frequently. Note that I could not load the driver when I was 
e.g. working on the kbd driver.

I stopped with this kind of usage once the console on sparc systems came up and 
has been too slow. OK there was a hack to copy the FORTH boot code into RAM to 
make it faster, but it still has been slower than the Sun2 or Sun3 machines.

Memory was definitely not a problem on Sparc systems as the Sparc systems I 
used never had less than 16MB of RAM (usually 64MB). I started with what I call 
a "SparcStation-1-" at home, an engineering sample delivered aprox. 9 months 
before the official Sparcstation-1 launch that used a TI Floatingpoint 
processor with a gate array adaptor on a piggy back rather than the official 
Weitek chip.

> Disclosure - never was an EMACS person, or a vi person, pico was and nano 
> is more my cup of tea.  That said, I can fumble my way around vi if I 
> absolutely must.

I do not know EMACS well enough to use it and I know vi for emergency only. I 
usually use my VED (see schilytools).

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Brantley Coile]

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

For the record, I use sam, ed, and acme, in that order.

> On Feb 25, 2017, at 1:11 PM, Joerg Schilling <schily at schily.net> wrote:
> 
> Steve Nickolas <usotsuki at buric.co> wrote:
> 
>> On Sat, 25 Feb 2017, Larry McVoy wrote:
>>> Back in the days of 4MB SPARC machines (and 68K machines) we joked
>>> that EMACS stood for Eight Megs And Constantly Swapping.  David
>>> Rosenthal, a Sun DE, was known for running emacs on the bitmapped
>>> console in terminal mode so as to not let X11 or NeWS eat up ram.
>>> 
>> 
>> From that nickname I came up with "Enough Memory A Concept Strange", as 8 
>> MB was no longer a lot of memory.
> 
> On my Sun-2/50 at home and my 3-50 at work, I edited in console mode when I was 
> working on drivers - just because launching Sunview did take too much time and 
> I needed to reboot frequently. Note that I could not load the driver when I was 
> e.g. working on the kbd driver.
> 
> I stopped with this kind of usage once the console on sparc systems came up and 
> has been too slow. OK there was a hack to copy the FORTH boot code into RAM to 
> make it faster, but it still has been slower than the Sun2 or Sun3 machines.
> 
> Memory was definitely not a problem on Sparc systems as the Sparc systems I 
> used never had less than 16MB of RAM (usually 64MB). I started with what I call 
> a "SparcStation-1-" at home, an engineering sample delivered aprox. 9 months 
> before the official Sparcstation-1 launch that used a TI Floatingpoint 
> processor with a gate array adaptor on a piggy back rather than the official 
> Weitek chip.
> 
>> Disclosure - never was an EMACS person, or a vi person, pico was and nano 
>> is more my cup of tea.  That said, I can fumble my way around vi if I 
>> absolutely must.
> 
> I do not know EMACS well enough to use it and I know vi for emergency only. I 
> usually use my VED (see schilytools).
> 
> Jörg
> 
> -- 
> EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
>       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
> URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Clem Cole]

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

On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy <lm at mcvoy.com> wrote:

> Back in the days of 4MB SPARC machines (and 68K machines) we joked
> ​ ​
> that EMACS stood for Eight Megs And Constantly Swapping.
>

​To me the good news is was if you could laugh at yourself I think it was
pretty sign.  There were a bunch of them... two more I can remember:

LISP -- Lots of Insipidly Silly Parens
Multics - Many Unbelievably Large Tables In Core Simultaneously ​

There was a Fortran one I've forgotten that started with "Friendly Only" ..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170225/f286ba59/attachment.html>

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Charles Anthony]

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

On Sat, Feb 25, 2017 at 9:31 AM, Clem Cole <clemc at ccc.com> wrote:

>
> On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> Back in the days of 4MB SPARC machines (and 68K machines) we joked
>> ​ ​
>> that EMACS stood for Eight Megs And Constantly Swapping.
>>
>
> ​To me the good news is was if you could laugh at yourself I think it was
> pretty sign.  There were a bunch of them... two more I can remember:
>
> LISP -- Lots of Insipidly Silly Parens
> Multics - Many Unbelievably Large Tables In Core Simultaneously ​
>
>
PCMCIA - 'People Can't Memorize Computer Industry Acronyms"

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

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Brantley Coile]

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

Compiles Only Because Of Luck.
Completely Obsolete, Badly Outdated Language
Even Feldman Likes it (The other FORTRAN.)

> On Feb 25, 2017, at 12:31 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy <lm at mcvoy.com> wrote:
> Back in the days of 4MB SPARC machines (and 68K machines) we joked​ ​that EMACS stood for Eight Megs And Constantly Swapping.
> 
> ​To me the good news is was if you could laugh at yourself I think it was pretty sign.  There were a bunch of them... two more I can remember:
> 
> LISP -- Lots of Insipidly Silly Parens
> Multics - Many Unbelievably Large Tables In Core Simultaneously ​
> 
> There was a Fortran one I've forgotten that started with "Friendly Only" ..
> 
> 
> 
> 

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Tim Bradshaw]

On 25 Feb 2017, at 17:31, Clem Cole <clemc at ccc.com> wrote:
> 
> LISP -- Lots of Insipidly Silly Parens

Lots of Irritating Single Parens

(Although why anyone who has looked at the tail of some bit of C-derived language with its apparently endless sequence of close braces, carefully arranged one-per line to maximise the wasted screen real-estate would say this is beyond me.  One of Python's few good features is that it is impossible to do this when writing Python -- although somewhere, no doubt, there are coding style guidelines which say that Python definitions must be separated from the following definition by 1 + number-of-nesting-levels blank lines.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170225/b98790c7/attachment.html>

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Dave Horsfall]

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

On Sat, 25 Feb 2017, Tim Bradshaw wrote:

> (Although why anyone who has looked at the tail of some bit of C-derived 
> language with its apparently endless sequence of close braces, carefully 
> arranged one-per line to maximise the wasted screen real-estate would 
> say this is beyond me.  One of Python's few good features is that it is 
> impossible to do this when writing Python -- although somewhere, no 
> doubt, there are coding style guidelines which say that Python 
> definitions must be separated from the following definition by 1 + 
> number-of-nesting-levels blank lines.)

The last language I used where white-space was syntactical was FORTRAN...  
Death to Python!

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Nemo]

On 25 February 2017 at 09:32, Larry McVoy <lm at mcvoy.com> wrote:
> On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno Griffioen wrote:
>> Worked quite well in the 4MB DRAM available on these cards. The later SVR4
>> didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!)
>> 16MB.
>
> Back in the days of 4MB SPARC machines (and 68K machines) we joked
> that EMACS stood for Eight Megs And Constantly Swapping.

Ah, EMACS jokes (though this be off-topic)!  I remember one cartoon,
which I cannot place, of someone at a terminal and a platter flying
through the room having broken free from the drive pack, the caption
reading "EMACS tends to hit the disc a little too often."

N.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Brantley Coile]

I remember in 1991 noticing suspiciously high load activity on a workstation of an engineer on vacation. Turns out he had just left EMACS running.

> On Feb 25, 2017, at 12:40 PM, Nemo <cym224 at gmail.com> wrote:
> 
> On 25 February 2017 at 09:32, Larry McVoy <lm at mcvoy.com> wrote:
>> On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno Griffioen wrote:
>>> Worked quite well in the 4MB DRAM available on these cards. The later SVR4
>>> didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!)
>>> 16MB.
>> 
>> Back in the days of 4MB SPARC machines (and 68K machines) we joked
>> that EMACS stood for Eight Megs And Constantly Swapping.
> 
> Ah, EMACS jokes (though this be off-topic)!  I remember one cartoon,
> which I cannot place, of someone at a terminal and a platter flying
> through the room having broken free from the drive pack, the caption
> reading "EMACS tends to hit the disc a little too often."
> 
> N.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Dave Horsfall]

On Sat, 25 Feb 2017, Larry McVoy wrote:

> Back in the days of 4MB SPARC machines (and 68K machines) we joked that 
> EMACS stood for Eight Megs And Constantly Swapping.  David Rosenthal, a 
> Sun DE, was known for running emacs on the bitmapped console in terminal 
> mode so as to not let X11 or NeWS eat up ram.

Another acronym is Esc Meta Alt Ctl Shift...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Noel Chiappa]

    > From: Dave Horsfall

    > Another acronym is Esc Meta Alt Ctl Shift...

Good one!

And there was a pretty funny fake Exxx error code - I think it was
"EMACS - Editor too big"?


I was never happy with the size of EMACS, and it had nothing to do with the
amount of memory resources used. That big a binary implies a very large amount
of source, and the more lines of code, the more places for bugs... And it
makes it harder to understand, for someone working on it (to make a
change/improvement).

        Noel

[TUHS] The size of EMACS, and what hides in kLOCs

[Michael Kjörling]

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

On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
> I was never happy with the size of EMACS, and it had nothing to do with the
> amount of memory resources used. That big a binary implies a very large amount
> of source, and the more lines of code, the more places for bugs...

But remember; without Emacs, we might never have had _The Cuckoo's
Egg_. Imagine the terror of that loss.

Or not. (Though Stoll's book was one of the things that more or less
introduced me to the idea of operating systems other than DOS/Windows.
I don't remember how many times I borrowed that book from the local
library, but it was probably in the double digits at least. Later I
got my own copy, which I still have.)

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] The size of EMACS, and what hides in kLOCs

[Nemo]

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

On 26 February 2017 at 07:46, Michael Kjörling <michael at kjorling.se> wrote:
> On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
>> I was never happy with the size of EMACS, and it had nothing to do with the
>> amount of memory resources used. That big a binary implies a very large amount
>> of source, and the more lines of code, the more places for bugs...
>
> But remember; without Emacs, we might never have had _The Cuckoo's
> Egg_. Imagine the terror of that loss.

Hhhmmm.... I must dig my copy out of storage because I do not remember
emacs in there.

As for emac uses, my wife was on (non-CS) staff at a local college
affiliated with U of T.  At the time, DOS boxes sat on staff desks and
email was via a telnet connection to an SGI box somewhere on campus.
A BATch file connected and ran pine but shelled out to an external
editor.  What was the editor?  Well, I saw her composing a message
once and ending the editor session by ^X^C.

N.

[TUHS] The size of EMACS, and what hides in kLOCs

[Michael Kjörling]

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

On 26 Feb 2017 11:05 -0500, from cym224 at gmail.com (Nemo):
> On 26 February 2017 at 07:46, Michael Kjörling <michael at kjorling.se> wrote:
>> But remember; without Emacs, we might never have had _The Cuckoo's
>> Egg_. Imagine the terror of that loss.
> 
> Hhhmmm.... I must dig my copy out of storage because I do not remember
> emacs in there.

In the translated text that I have, the hacker relied primarily on
Emacs' mail feature to move the compromised atrun into place for
execution, in order to gain temporary root privileges. It is possible
that Stoll's original English text is more specific about which exact
feature was used; the translation does leave a little to be desired in
places where it's actually noticable even without having seen the
original, so I would not hold it beyond the translator (in 1991; gosh,
that's over a quarter of a century ago now) to not be completely
familiar with the finer points of Unix editors, or possibly even
wanting to simplify a little for a _readership_ that couldn't be
expected to.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] The size of EMACS, and what hides in kLOCs

[Tim Bradshaw]

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

On 26 Feb 2017, at 17:05, Michael Kjörling <michael at kjorling.se> wrote:
> 
> In the translated text that I have, the hacker relied primarily on
> Emacs' mail feature to move the compromised atrun into place for
> execution, in order to gain temporary root privileges.

This was the movemail SUID bug, and it's indeed in the original although I'm not sure how much detail he goes into.

[TUHS] The size of EMACS, and what hides in kLOCs

[Jim Carpenter]

On Sun, Feb 26, 2017 at 1:23 PM, Tim Bradshaw <tfb at tfeb.org> wrote:
> This was the movemail SUID bug, and it's indeed in the original although I'm not sure how much detail he goes into.

Not much detail:

"""
    In the way it was installed on our Unix computer, the Gnu-Emacs editor
lets you forward a mail file from your own directory to anyone else in an
unusual way. It doesn't check to see who's receiving it, or even whether they
want the file. It just renames the file and changes its ownership label. You've
just transferred ownership of the file from you to me.

    No problem to sent a file from your area to mine. But you'd better not
be able to move a file into the protected systems area: only the system
manager is allowed there. Stallman's software had better make sure this can't
happen.

    Gnu didn't check. It let anyone move a file into protected systems
space. The hacker knew this; we didn't.

    The hacker used Gnu to swap his special atrun file for the system's
legitimate version. Five minutes later, the system hatched his egg, and he
held the keys to my computer.
"""

Jim

[TUHS] EMACS movemail suid root bug

[Michael Kjörling]

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

On 26 Feb 2017 14:19 -0500, from jim at deitygraveyard.com (Jim Carpenter):
>     No problem to sent a file from your area to mine. But you'd better not
> be able to move a file into the protected systems area: only the system
> manager is allowed there. Stallman's software had better make sure this can't
> happen.
> 
>     Gnu didn't check. It let anyone move a file into protected systems
> space. The hacker knew this; we didn't.

That agrees well with my translated version.

So in a sense, everything that the Emacs movemail (thanks Tim) bug
allowed you to do was _really_ enabled by the fact that there existed
a user SOMEONE, for which ~SOMEONE was a directory, _used at least in
part for privileged purposes by the operating system_, to which
ordinary users were expected to not have any write access?

Consequently, if system (as opposed to regular user) accounts had had
a home directory set to something else, some place where it didn't
really matter if an unprivileged user was able to drop files, then
that bug would have been a nuisance (giving random users the ability
to take up disk space unaccounted for, requiring clean-up) but not
really the problem it became?

Looking at my modern Debian system, I see users in /etc/passwd with
home directories like /bin, /usr/sbin, /var/spool/postfix, /proc,
/var/run/sshd, within but not actually /etc, ... So in effect, we are
still to a large degree relying on people not making the same kind of
mistake that was made in movemail when writing code that runs suid
root. I know that anything running as suid root is potentially very
dangerous, but that seems like a trivial mitigative strategy. (When
was the last time anyone logged in as "daemon" on a modern Linux
system, let alone needed their home directory then to be /usr/sbin?)

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] The size of EMACS, and what hides in kLOCs

[Nemo]

On 26 February 2017 at 12:28, Andy Kosela <andy.kosela at gmail.com> wrote:
[...]
> Are you sure it was emacs?  Most probably it was pico, which was the default
> editor for pine.  We used pine/pico for all email at our university in the
> 90's.  It was wildly popular.

Ah well, I am not sure -- that betrayed my emacs bias.  I saw ^X^C and
assumed emacs.

N.

[TUHS] The size of EMACS, and what hides in kLOCs

[Steve Nickolas]

On Sun, 26 Feb 2017, Nemo wrote:

> On 26 February 2017 at 12:28, Andy Kosela <andy.kosela at gmail.com> wrote:
> [...]
>> Are you sure it was emacs?  Most probably it was pico, which was the default
>> editor for pine.  We used pine/pico for all email at our university in the
>> 90's.  It was wildly popular.
>
> Ah well, I am not sure -- that betrayed my emacs bias.  I saw ^X^C and
> assumed emacs.
>
> N.
>

Huh.  pico's exit is just ^X, not ^X^C.

-uso.

[TUHS] The size of EMACS, and what hides in kLOCs

[Michael Kjörling]

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

On 26 Feb 2017 20:48 -0500, from usotsuki at buric.co (Steve Nickolas):
>> On 26 February 2017 at 12:28, Andy Kosela <andy.kosela at gmail.com> wrote:
>>> Are you sure it was emacs?  Most probably it was pico, which was the default
>>> editor for pine.
>> 
>> Ah well, I am not sure -- that betrayed my emacs bias.  I saw ^X^C and
>> assumed emacs.
> 
> Huh.  pico's exit is just ^X, not ^X^C.

Yes. Pico and Nano have pretty much the same key bindings for
everything that both have (there may be some minor exception), and ^X
triggers an exit. If there are any unsaved changes, it will ask what
to do; hitting ^C at that point brings you right back to the editor.

Wikipedia puts Pine's birth at 1989, and public announcement in 1992,
so that would be reasonably believable with DOS boxen as terminals...

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] The size of EMACS, and what hides in kLOCs

[Jason Stevens]

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

Emacs was the central exploit that "Jagger" used to gain root access once he got his way on a box.

It's a fantastic book, with good lessons in there that still ring true, such as keeping a log, documenting what you did and why, not emailing passwords and running a honeypot.

It also showed that if you weren't in the clique you didn't get source access and that finding even part of it was a big deal.

It's a shame his next book, silicone snake oil missed the mark by so much.

On February 27, 2017 12:05:19 AM GMT+08:00, Nemo <cym224 at gmail.com> wrote:
>On 26 February 2017 at 07:46, Michael Kjörling <michael at kjorling.se>
>wrote:
>> On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel
>Chiappa):
>>> I was never happy with the size of EMACS, and it had nothing to do
>with the
>>> amount of memory resources used. That big a binary implies a very
>large amount
>>> of source, and the more lines of code, the more places for bugs...
>>
>> But remember; without Emacs, we might never have had _The Cuckoo's
>> Egg_. Imagine the terror of that loss.
>
>Hhhmmm.... I must dig my copy out of storage because I do not remember
>emacs in there.
>
>As for emac uses, my wife was on (non-CS) staff at a local college
>affiliated with U of T.  At the time, DOS boxes sat on staff desks and
>email was via a telnet connection to an SGI box somewhere on campus.
>A BATch file connected and ran pine but shelled out to an external
>editor.  What was the editor?  Well, I saw her composing a message
>once and ending the editor session by ^X^C.
>
>N.

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

[TUHS] The size of EMACS, and what hides in kLOCs

[Nick Downing]

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

Hmmm Emacs... Editor too large :)

Well I don't use Emacs because it is the opposite of minimal, I mean
partly from a purist standpoint, partly from a practical standpoint
since we often have to do things like editing fstab before the system
is fully up. I think Joerg mentioned use of vi "for emergencies" and
that is always gonna be necessary, even for the Emacs people here. But
if I'm gonna learn something "for emergencies" I'd probably rather
just standardize on it, as I have done with vi.

That's not to say I like vi, in fact I detest it, it is clunky and
counterintuitive and modal and... I just can't stand the way it puts
the cursor "on" the current character, so that you have to use "i" to
insert before or "a" to insert after... and you can't standardize on
"i" or "a" since "i" is needed at the start of the line and "a" at the
end of the line... I can't stand the way it's line-oriented (obviously
to do with its "ex" heritage) and so you can't search on ^M (can
replace, luckily). I also have never fully bothered to learn the "vi"
command set since I felt I was kind of "camping" until I found a
better alternative, so I have improvised some truly strange sequences
to do common things like deleting a line. Haha. And recently when I
was working in the simulator with "old vi" rather than vim, I
discovered it has some really bad limitations like line length...
HOPEFULLY these are removed in "new vi", I will have to try reno in
the simulator some time.

But now to the point of my post, which is a bit of a convoluted story
that DOES touch on Emacs at the end. Well way back in the early 80s
when people believed that MSDOS would be distributed with a custom
BIOS per machine like CP/M was... and each manufacturer had their
MSDOS solution which was generally an 8086 or 8088 at around 5 MHz and
wasn't IBM compatible... various relatives of mine did their own
market research and bought interesting MSDOS machines. The most
interesting and powerful at the time was my uncle's Victor 9000 aka
Apricot ACT, it was a very futuristic machine for its time, with an
800x600 monochrome text and graphic display, variable speed floppies,
I think he had 256k or maybe 512k in it, but it could go up to about
768k or more, unlike IBM's later PC. And, with the Victor 9000 was
shipped a pretty good development system including... a text editor of
TRULY AMAZING abilities.

So the text editor was called PMATE, and it was supplied by Phoenix
Software Associates (P=Phoenix MATE=Original name of the editor before
they licensed it from its author). Yep that's Phoenix that later
became famous for BIOSes. Later on they ported PMATE to IBM XT as
well, basically they just changed the memory mapped screen to B000 or
B800 as required by IBM's MDA or CGA respectively. I used PMATE for
many years, it had an unbelievably great macro language, it had 10
buffers, you could put macros or text in each buffer, buffers could
execute each other, it could grab text into a buffer and reinsert it
somewhere else in your document, it could do search and replace with
wildcards (not regular expressions unfortunately), it could do integer
math (without operator precedence), it had various stacks and
variables and control flow and looping constructs, various disk
buffering modes and other settings.

So using PMATE I was unbelievably productive, it was great for
software development and for stuff like data entry or letter writing
too. For instance my mum was secretary of the basketball club that
myself and my brothers played for, we used to manage team lists and
mailing lists and fixtures etc, as text files in PMATE, and when we
were ready to do a mailout, we would have PMATE do a very specialized
merge of all kinds of data from different files, and then generate an
output that would be imported into WordPerfect 5.1 and laser printed.
Another time a guy was doing an election campaign and he wanted all
the electoral rolls for our district typed in (paper form was
available from public record). So I got a bunch of friends together
and we spent a week typing stuff into PMATE, after I implemented an
autocomplete facility in macros that significantly sped things up by
copying stuff from the previous line entered, etc etc. (The guy paid
us about $4000 for this, and we spent part of the money buying a
Streetfighter II arcade machine that was then communally owned by the
group which I had got together to do the data entry job, very fun
times for all :) )

Sad to say, the day came when PMATE had to be retired as I had
switched over my primary development first to Windows (where PMATE
worked but limped a bit due to its 64K limitation, despite all the
tricky disk buffering it had), and then to Linux where PMATE did not
work. I briefly tried running it under emulation. I did use the
configuration utility to patch it to generate ANSI type scape
sequences instead of using the memory mapped screen, and I even did
some CP/M to native disk access translation (I was using the Z80
version which was called ZMATE, since the 8088 port didn't offer
significant advantages in this setting). It was more or less useable,
but just too clunky for everyday use compared with vi. Anyway I deeply
mourned the loss and spent years trying to reverse engineer it, I did
at one stage make a 386 version that worked under a DOS extender, but
it would occasionally crash and I never got it debugged.

In the course of all this I was VERY VERY keen to understand more
about PMATE, finding the 8080 and Z80 versions on a little used CP/M
archive was helpful, anyway it is written by a guy called Michael
Aronsen (Arunsen?) and hence got it's name "Michael Aronsen's Text
Editor". I was thinking what a genius this guy is and wondering why he
dropped out of the scene and is no longer to be found anywhere online.
I guess it was just a college project he did because he needed an
editor, and eventually he sold it to Phoenix and washed his hands of
it. WELL strangely whenever I searched for MATE or PMATE, as well as
lots of advertisements for the Pee-Mate (a device which allows women
to pee into a bottle during lectures or long train trips etc), it
would often come up on lists of TECO implementations. I ignored this,
having no idea what TECO was, or if I briefly looked at it, then I
missed the true significance.

Well lately, there was a reference on this list to LUSERing and the
Incompatible Timesharing System (ITS), and I was idly browsing
Wikipedia etc about ITS, reading some technical documents etc, and
there was a lot of mention of Teco, this piqued my interest so I
downloaded something like Tecoc or Video Teco and compiled it and gave
it a shot... LO AND BEHOLD, PMATE IS REINCARNATED!!!!





On Mon, Feb 27, 2017 at 12:19 PM, Jason Stevens
<jsteve at superglobalmegacorp.com> wrote:
> Emacs was the central exploit that "Jagger" used to gain root access once he
> got his way on a box.
>
> It's a fantastic book, with good lessons in there that still ring true, such
> as keeping a log, documenting what you did and why, not emailing passwords
> and running a honeypot.
>
> It also showed that if you weren't in the clique you didn't get source
> access and that finding even part of it was a big deal.
>
> It's a shame his next book, silicone snake oil missed the mark by so much.
>
>
> On February 27, 2017 12:05:19 AM GMT+08:00, Nemo <cym224 at gmail.com> wrote:
>>
>> On 26 February 2017 at 07:46, Michael Kjörling <michael at kjorling.se>
>> wrote:
>>>
>>>  On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
>>>>
>>>>  I was never happy with the size of EMACS, and it had nothing to do with
>>>> the
>>>>  amount of memory resources used. That big a binary implies a very large
>>>> amount
>>>>  of source, and the more lines of code, the more places for bugs...
>>>
>>>
>>>  But remember; without Emacs, we might never have had _The Cuckoo's
>>>  Egg_. Imagine the terror of that loss.
>>
>>
>> Hhhmmm.... I must dig my copy out of storage because I do not remember
>> emacs in there.
>>
>> As for emac uses, my wife was on (non-CS) staff at a local college
>> affiliated with U of T.  At the time, DOS boxes sat on staff desks and
>> email was via a telnet connection to an SGI box somewhere on campus.
>> A BATch file connected and ran pine but shelled out to an external
>> editor.  What was the editor?  Well, I saw her composing a message
>> once and ending the editor session by ^X^C.
>>
>> N.
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Tim Bradshaw]

On 26 Feb 2017, at 12:39, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> I was never happy with the size of EMACS, and it had nothing to do with the
> amount of memory resources used. That big a binary implies a very large amount
> of source, and the more lines of code, the more places for bugs... And it
> makes it harder to understand, for someone working on it (to make a
> change/improvement).

I think whether you think Emacs is large or small depends on what you think it is.  If you think it's a text editor it's huge (by the standards of the 1970s, anyway: I have things which purport to be text editors which have python interpreters in and are significantly larger than Emacs, *on my phone*).   But if you think of it as the userland of an operating system it's rather small.  And many Emacs users do (or did: I used to but don't so much any more) treat it as the latter.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Michael Kerpan]

Oops. Meant to send this to this list but sent it privately. Here's a
second try:

My supposition is that EMACS was basically Stallman's attempt to bring in
all the things he liked about the LISP Machine environment into the Unix
world through the back door. The original PDP-10 EMACS really was just a
pile of macros which turned TECO into something usable by mere mortals. If
all you wanted was an editor that worked the same way as PDP-10 EMACS, it
would have been easy to create: several people have (MicroEMACS, etc). It's
the fact that GNU EMACS was intended as a haven for MIT LISP hackers adrift
in the bold new world of Unix that made it so huge for its time.

Mike

On Feb 26, 2017 8:40 AM, "Tim Bradshaw" <tfb at tfeb.org> wrote:

> On 26 Feb 2017, at 12:39, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> >
> > I was never happy with the size of EMACS, and it had nothing to do with
> the
> > amount of memory resources used. That big a binary implies a very large
> amount
> > of source, and the more lines of code, the more places for bugs... And it
> > makes it harder to understand, for someone working on it (to make a
> > change/improvement).
>
> I think whether you think Emacs is large or small depends on what you
> think it is.  If you think it's a text editor it's huge (by the standards
> of the 1970s, anyway: I have things which purport to be text editors which
> have python interpreters in and are significantly larger than Emacs, *on my
> phone*).   But if you think of it as the userland of an operating system
> it's rather small.  And many Emacs users do (or did: I used to but don't so
> much any more) treat it as the latter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/89b49fd0/attachment.html>

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Joerg Schilling]

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

Michael Kerpan <madcrow.maxwell at gmail.com> wrote:

> Oops. Meant to send this to this list but sent it privately. Here's a
> second try:
>
> My supposition is that EMACS was basically Stallman's attempt to bring in
> all the things he liked about the LISP Machine environment into the Unix
> world through the back door. The original PDP-10 EMACS really was just a
> pile of macros which turned TECO into something usable by mere mortals. If
> all you wanted was an editor that worked the same way as PDP-10 EMACS, it
> would have been easy to create: several people have (MicroEMACS, etc). It's
> the fact that GNU EMACS was intended as a haven for MIT LISP hackers adrift
> in the bold new world of Unix that made it so huge for its time.

But the GNU EMACS is not a RMS invention...

GNU EMACS is based on the Gosling EMACS and this did already include the LISP 
interpreter.

When Gosling started to work for Sun, he did no longer have the time to 
maintain it and did hand it over to Unipress. RMS did take this code, added a 
few small changed and sold it under the name GNU emacs.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Angelo Papenhoff]

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

Whoops, replied off list too accidentally, sorry Jörg.

On 26/02/17, Joerg Schilling wrote:
> But the GNU EMACS is not a RMS invention...
> 
> GNU EMACS is based on the Gosling EMACS and this did already include the LISP 
> interpreter.
> 
> When Gosling started to work for Sun, he did no longer have the time to 
> maintain it and did hand it over to Unipress. RMS did take this code, added a 
> few small changed and sold it under the name GNU emacs.

As far as I know the original LISP implementation in Gosling EMACS had
to be completely rewritten. I just don't remember where I've read this.

aap

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Joerg Schilling]

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

Angelo Papenhoff <aap at papnet.eu> wrote:

> Whoops, replied off list too accidentally, sorry Jörg.

Woops replied off list as well...

Angelo Papenhoff <aap at papnet.eu> wrote: 
 
> On 26/02/17, Joerg Schilling wrote: 
> > GNU EMACS is based on the Gosling EMACS and this did already include the 
LISP  
> > interpreter. 
> >  
> > When Gosling started to work for Sun, he did no longer have the time to  
> > maintain it and did hand it over to Unipress. RMS did take this code, added 
a  
> > few small changed and sold it under the name GNU emacs. 
> 
> As far as I know the original LISP implementation in Gosling EMACS had 
> to be completely rewritten. I just don't remember where I've read this. 
 
Unipress asked RMS to rewrite the screen update code before distributing it as  
GNU emacs or they will sue RMS. 
 
It is not clear how much of the code was really rewritten. What I can tell is  
that the GNU emacs uses a screen update that is as slow as the original code  
from Gosling that Gosling took from another own project - an ASCII art editor  
that needed to be able to handle more than one simultaneous change at a time. 
 
My background is that I did a lot of benchmarking on Gosling Emacs, GNU Emacs,  
vi and my VED around 1985.  
 
It turned out that RMS may have rewritten the code but did not change the  
algorithm. My own screen update from VED is much faster even though it can 
only handle either a single deletion or a single insertion at a time. Changes
are implemented as a delete operation followed by an insert operation ahd 
this turns out to be much faster than what emacs does.  
 
BTW: one reason why emacs is slow is that the status line is at the bottom  
rather than being the top line as in VED. If you use emacs on a real terminal,  
you see the status line hopping... 
 
The oldest changelog file in GNU emacs claims on the bottom line something 
like: "Now all Gosling code has been rewritten". Given the fact that the
screen update still basically uses the same algorithm, it is not clear what 
this statement means. 

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Tim Bradshaw]

> On 26 Feb 2017, at 14:54, Joerg Schilling <schily at schily.net> wrote:
> 
> GNU EMACS is based on the Gosling EMACS and this did already include the LISP 
> interpreter.

Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp.  GNU Emacs has elisp which *is* a Lisp (albeit a fairly horrid one).

There's no doubt that GNU Emacs had its roots in Gosling Emacs, but only in much the same way that FreeBSD has its roots in 6th edition Unix.

There's also no real doubt that RMS was responsible for Emacs *as an idea* as opposed to any particular implementation (Guy Steele is I think the other person who might be held responsible, but I believe he's said that it was RMS, which is good enough for me).

--tim

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Joerg Schilling]

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

Tim Bradshaw <tfb at tfeb.org> wrote:

>
> > On 26 Feb 2017, at 14:54, Joerg Schilling <schily at schily.net> wrote:
> > 
> > GNU EMACS is based on the Gosling EMACS and this did already include the LISP 
> > interpreter.
>
> Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp.  GNU Emacs has elisp which *is* a Lisp (albeit a fairly horrid one).

OK, then Gosling just had the idea of including lisp.

> There's also no real doubt that RMS was responsible for Emacs *as an idea* as opposed to any particular implementation (Guy Steele is I think the other person who might be held responsible, but I believe he's said that it was RMS, which is good enough for me).

I am sure that emacs would be unknown today in case that Gosling did not write 
the C-implementation.

A macro set for a closed source editor on a dying architecture (PDP-11) 
would have died as well.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[tfb]

On 26 Feb 2017, at 15:52, Joerg Schilling <schily at schily.net> wrote:
> 
> OK, then Gosling just had the idea of including lisp.

I'd have to check the chronology but I'm fairly sure that EINE predates Gosling Emacs by several years: I'd assume that either EINE is where Gosling got the idea, or that it was just obvious, since Emacs came from an environment where implementing things in Lisp was not a strange idea, to put it rather mildly.

(Note I agree that Gosling Emacs is the root of Emacs-on-Unix and that without that Emacs would likely have died out with the platforms it lived on.)

--tim

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Ron Natalie]

Tim is right.   EINE predates Gosling's EMACS by a few years.   Of course,
it uses LISP as an extension language not because they thought that would be
novel but since the whole thing was implemented in LISP to begin with (much
as you could extend the TECO EMACS with more TECO).

And you are right, since EMACS (both the TECO and EINE and other variants)
were coming out of the AI realm where LISP prevails, using LISP as a
language certainly made sense.   It was also really easy to implmenet a
cheap mocklisp parser as Gosling did in the an otherwise C language
implementation.

I worked with Gosling and his successor Mike Gallaher (at Unipress) for
years on the Unipress commercialization of Gosling's EMACS (I had been using
the early non-commercial version at BRL).    Gosling was a big fan of
programmable interfaces.   From the EMACS mocklisp, he went to developing
the NeWS window system (which used a variant of PostScript as it's language)
and then on to JAVA.    I did a bunch of stuff with NeWS and Gallaher's
subsequent similar extension module SoftWire (also commercially used by my
company as PixScript).    Even with Owen Densmore's (Sun Microsystems)
object oriented changes, it was a horrendous language to actually write
stuff in.   



-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of tfb@tfeb.org


I'd have to check the chronology but I'm fairly sure that EINE predates
Gosling Emacs by several years: I'd assume that either EINE is where Gosling
got the idea, or that it was just obvious, since Emacs came from an
environment where implementing things in Lisp was not a strange idea, to put
it rather mildly.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Lars Brinkhoff]

"Ron Natalie" <ron at ronnatalie.com> writes:
> > I'd have to check the chronology but I'm fairly sure that EINE
> > predates Gosling Emacs by several years: I'd assume that either EINE
> > is where Gosling got the idea, or that it was just obvious, since
> > Emacs came from an environment where implementing things in Lisp was
> > not a strange idea, to put it rather mildly.
> Tim is right.   EINE predates Gosling's EMACS by a few years.   Of course,
> it uses LISP as an extension language not because they thought that would be
> novel but since the whole thing was implemented in LISP to begin with (much
> as you could extend the TECO EMACS with more TECO).

RMS credits Multics Emacs with the idea to use Lisp as the extension
language:

    The language that you build your extensions on shouldn't be thought
    of as a programming language in afterthought; it should be designed
    as a programming language. In fact, we discovered that the best
    programming language for that purpose was Lisp.

    It was Bernie Greenberg, who discovered that it was. He wrote a
    version of Emacs in Multics MacLisp, and he wrote his commands in
    MacLisp in a straightforward fashion. The editor itself was written
    entirely in Lisp. Multics Emacs proved to be a success great
    programming new editing commands was so convenient that even the
    secretaries in his office started learning how to use it.

https://www.gnu.org/gnu/rms-lisp.html

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Tony Finch]

Lars Brinkhoff <lars at nocrew.org> wrote:
>
> RMS credits Multics Emacs with the idea to use Lisp as the extension
> language: [snip] https://www.gnu.org/gnu/rms-lisp.html

There's a nice history / retrospective of Multics Emacs at
http://www.multicians.org/mepap.html

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Dogger, Fisher: South becoming cyclonic 5 to 7, occasionally gale 8 later.
Moderate or rough, occasionally very rough later. Rain or showers. Moderate or
good.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Nick Downing]

Really fascinating reading (the emacs history essay). I had more or less
gone through a similar thought process in my own editor experiments, such
as a failed attempt to provide full screen editing for email in
TheMajorBBS, it's a difficult and fascinating problem and the dicussion of
FNP char-at-a-time patches is quite revealing in regards to the limitations
(both physical and idealogical) that prevailed with early mainframes.
cheers, Nick

On Feb 28, 2017 3:05 AM, "Tony Finch" <dot at dotat.at> wrote:

> Lars Brinkhoff <lars at nocrew.org> wrote:
> >
> > RMS credits Multics Emacs with the idea to use Lisp as the extension
> > language: [snip] https://www.gnu.org/gnu/rms-lisp.html
>
> There's a nice history / retrospective of Multics Emacs at
> http://www.multicians.org/mepap.html
>
> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h
> punycode
> Dogger, Fisher: South becoming cyclonic 5 to 7, occasionally gale 8 later.
> Moderate or rough, occasionally very rough later. Rain or showers.
> Moderate or
> good.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170228/5067acb7/attachment.html>

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Michael Kerpan]

On Feb 26, 2017 10:52 AM, "Joerg Schilling" <schily at schily.net> wrote:

Tim Bradshaw <tfb at tfeb.org> wrote:

>
> > On 26 Feb 2017, at 14:54, Joerg Schilling <schily at schily.net> wrote:
> >
> > GNU EMACS is based on the Gosling EMACS and this did already include
the LISP
> > interpreter.
>
> Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp.
GNU Emacs has elisp which *is* a Lisp (albeit a fairly horrid one).

OK, then Gosling just had the idea of including lisp.

IIRC, Gosling EMACS was mainly written in C, and Mocklisp was merely an
extension language. GNU EMACS is mostly written in LISP, with the C mainly
being used to implement the LISP interpreter. That's a pretty big
architectural difference there.

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

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Ron Natalie]

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

Gosling Emacs was indeed written in C.   But so is/was GNU EMACS.   It started by outright stealing not only one of Gosling’s earlier (pre-commercial) releases but RMS made off with improvements done at UNIPRESS.

However, after much wrangling between James, Unipress, and RMS, RMS backed out the stuff stolen from UNIPRESS and chucked out Gosling’s “mocklisp” interpretter for what RMS felt was a more correct “mlisp” implementation.    Of course, most of the lisp stuff was largely original to RMS’s project.    This accounts for the really anti-UNIX ugliness in some of his keybindings that is always the thing I program when I have to use a Xemacs implementation (who the hell thought using BACKSPACE for “help” was a good idea?   Well I know who, his maloderous self used to show up at my house from time to time).

 

My coworkers always used to laugh at me.   If there was no EMACS-like editor on the machine (I also variously used Montgomery’s EMACS and finally JOVE) on smaller machines that GosMacs was too heavy for), I would just use “ed” (having been a master of that from when that was all there was).    I never learned vi, and if I was stuck using it, I ran it in ex mode.     I had a brief stint with the RandEditor AKA Interactive Systems editor derived from it (InED).

 

 

From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Michael Kerpan
Sent: Sunday, February 26, 2017 11:23 AM
To: tuhs at tuhs.org
Subject: Re: [TUHS] Un-released/internal/special UNIX versions/ports during the years?

 

On Feb 26, 2017 10:52 AM, "Joerg Schilling" <schily at schily.net> wrote:

Tim Bradshaw <tfb at tfeb.org> wrote:

>
> > On 26 Feb 2017, at 14:54, Joerg Schilling <schily at schily.net> wrote:
> >
> > GNU EMACS is based on the Gosling EMACS and this did already include the LISP
> > interpreter.
>
> Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp.  GNU Emacs has elisp which *is* a Lisp (albeit a fairly horrid one).

OK, then Gosling just had the idea of including lisp.

IIRC, Gosling EMACS was mainly written in C, and Mocklisp was merely an extension language. GNU EMACS is mostly written in LISP, with the C mainly being used to implement the LISP interpreter. That's a pretty big architectural difference there.

 

Mike

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

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[William Pechter]

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

Ron Natalie wrote:
>
> Gosling Emacs was indeed written in C.   But so is/was GNU EMACS. It 
> started by outright stealing not only one of Gosling’s earlier 
> (pre-commercial) releases but RMS made off with improvements done at 
> UNIPRESS.
>
> However, after much wrangling between James, Unipress, and RMS, RMS 
> backed out the stuff stolen from UNIPRESS and chucked out Gosling’s 
> “mocklisp” interpretter for what RMS felt was a more correct “mlisp” 
> implementation.    Of course, most of the lisp stuff was largely 
> original to RMS’s project. This accounts for the really anti-UNIX 
> ugliness in some of his keybindings that is always the thing I program 
> when I have to use a Xemacs implementation (who the hell thought using 
> BACKSPACE for “help” was a good idea?   Well I know who, his 
> maloderous self used to show up at my house from time to time).
>
> My coworkers always used to laugh at me.   If there was no EMACS-like 
> editor on the machine (I also variously used Montgomery’s EMACS and 
> finally JOVE) on smaller machines that GosMacs was too heavy for), I 
> would just use “ed” (having been a master of that from when that was 
> all there was).    I never learned vi, and if I was stuck using it, I 
> ran it in ex mode.     I had a brief stint with the RandEditor AKA 
> Interactive Systems editor derived from it (InED).
>
>
Interesting how the Rand Editor seems to have been the choice of many.
Perkin-Elmer (later Concurrent) based their in-house office automation 
software
("Paper Free in '83.") On dog-slow UniPlus SysIII (IIRC -- later MicroXelos
UniPlus SysV based I think) on 68000 cpu 8 mhz machines.  No virtual memory
a dog-crap slow video subsystem.

Of course I got a truck load of them when they dumped them and I used
them to do the two county wide newsfeed until the PC Unix stuff
became available.

http://www.1000bit.it/ad/bro/perkin/PerkinElmer7350.pdf

The nice one I had was an XF200 MicroXelos box -- which was RARE.
It was a minitower without the graphics and with room for a pair of
80mb MFM drives.

Did one of 'em for system and user accts and one for partial newsfeed.

-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Lars Brinkhoff]

Tim Bradshaw <tfb at tfeb.org> writes:
> There's also no real doubt that RMS was responsible for Emacs *as an
> idea* as opposed to any particular implementation (Guy Steele is I
> think the other person who might be held responsible, but I believe
> he's said that it was RMS, which is good enough for me).

Here's what they wrote about that 6 Jul 1978.

RMS:

    The work done by GLS was
      a) to consider a large number of possible command sets, and
         suggest many interesting possible commands, and
      b) to begin doing actual work (on the purifier and start-up).
         Although none of this code survived after a week or so, I might
         never have been able to start doing anything if left to myself.
         I often have trouble getting off the ground.

GLS:

    The account of my involvement given by RMS is essentially accurate.
    I started [EMACS] because I was getting tired of the kludginess of
    the TCMAC command arrangement, and saw in other editors neat
    commands that could not be fit cleanly into TECMAC.  I therefore
    decided to perform a total reorganization of the command structure,
    and carefully examine all the other existing TECO-based editors,
    such as RMODE, DOC, and the ever-popular TMACS.  Most of my work
    involved playing with assignments of commands to keys, and running
    around organizing discussions and soliciting comments.  I made an
    initial stab at a loader, and I think I invented (or re-invented)
    the notion of a compressing loader, and invented most of the
    specific conventions for the EMACS loader (such as using _ for a
    space), though these conventions were greatly refined later.  It was
    at about this point that RMS and others took over the development
    work, and did a much better job, much faster, than I could have.
    For this reason, as well as the pressure of classes and the
    maintenance of LISP, I was happy to let others take over [EMACS].
    Thus, while I provided initial impetus and much of the original
    user-level command structure, most of the development work and
    succeeding refinements is to the credit of other people.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Tim Bradshaw]

On 26 Feb 2017, at 14:19, Michael Kerpan <madcrow.maxwell at gmail.com> wrote:
> 
> My supposition is that EMACS was basically Stallman's attempt to bring in all the things he liked about the LISP Machine environment into the Unix world through the back door. 

I think this is at least partly right, although either RMS didn't like most of the really interesting things about the LispM environments or he was not involved in many of the developments which made them interesting: I suspect at least partly the latter as he presumably stopped being involved when Symbolics became seriously independent from the MIT AI lab and/or the hardware became too divergent (the 3600 I guess: I don't know if the AI lab had lots of those, they were certainly eye-wateringly expensive for those of us bought up on Suns).  It may also be that a lot of the LispM stuff was genuinely hard to support on hardware which, for instance, wanted to distinguish between the OS and userland in any serious way until much later, although I'm reluctant to believe that.

Slightly more on-topic, it seems to me really interesting that both the LispM & Unix environments really aim at providing comfortable places for programmers to work in, and specifically for the people writing the OS to work in (as opposed to some other OSs which clearly were more aimed at production applications) but they did it in such enormously different ways.  Some of this has been fairly well-explored I think, by the famous 'worse is better' paper & its successors, but I don't think that's the whole answer.

Both Unix and the LispMs encourage a way of working where you build little tools to do things, often things that get used only a few times, but the *way* you do that is completely different.  And Unix is ultimately the better answer I think, because you can build a LispM-type environment on Unix but you can't realistically do it the other way around (the filesystem on LispMs was not up to what you'd want to run a Unix-style world on top of it, for one thing).

So I don't think that this has really been sorted-out yet: certainly I'm confused and I've spent a lot of time in both worlds.

--tim

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Ron Natalie]

> Slightly more on-topic, it seems to me really interesting that both the
LispM & Unix environments really aim at providing comfortable places for
programmers to work in, and specifically for the people writing the OS to
work in (as opposed to some other OSs which clearly were more aimed at
production applications) but they did it in such enormously different ways.



Isn't that what Programmer's WorkBench was alp about.   We had picked up
random stuff out of PWB (notably the shell) at JHU, but didn't really use
the PWB aspects of it.   My first job after college (intermixed with writing
some design documents for the database system I was supposed to be working
on ) was helping the QA department setup the procedures to use PWB (SCCS and
various other things) to implement the software engineering environment.
While PWB was sort of targeted on RJE submittal to IBM mainframes, we were
using it to control the software development for a RSX-11M based
intelligience system.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Ron Natalie]

RMS had pretty much left both the LISP machine and the DEC MAINFRAME (TOPS20 and ITS) by the time he got around to creating EMACS, he started GNU because he wanted a new super system and he figured starting with UNIX which he regarded (if you read the manifesto) as incredibly deficient.   The idea was to come up with a  new UNIX-ish kernel with all the crap he had come accustomed to on the LISP machines and iTS.   Of course, he got run over by LINUX along the way.

 

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

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Michael Kjörling]

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

On 26 Feb 2017 12:15 -0500, from ron at ronnatalie.com (Ron Natalie):
> Of course, he got run over by LINUX along the way.

...and even today, while the GNU userland sees reasonable use (just
about every Linux distribution targetting the desktop or server niches
use it, except for the few minimalistic ones that rely primarily on
Busybox, so it's pretty hard to run Linux and not GNU), GNU Hurd lives
a life of obscurity and few even know what it is, let alone knows
anyone who uses it for anything even half-way serious.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Ron Natalie]

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

I didn't say that GNU wasn't a necessary part, it's just I think RMS feels he lost control of things when LINUX displaced his plans for the kernel.   Obviously, much of the user mode is entirely beholden to the GNU project starting with GCC and the run tlime libraries.    The only major system that really isn't is the display system which is X.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Michael Kjörling
Sent: Sunday, February 26, 2017 12:20 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Un-released/internal/special UNIX versions/ports during the years?

On 26 Feb 2017 12:15 -0500, from ron at ronnatalie.com (Ron Natalie):
> Of course, he got run over by LINUX along the way.

...and even today, while the GNU userland sees reasonable use (just about every Linux distribution targetting the desktop or server niches use it, except for the few minimalistic ones that rely primarily on Busybox, so it's pretty hard to run Linux and not GNU), GNU Hurd lives a life of obscurity and few even know what it is, let alone knows anyone who uses it for anything even half-way serious.

--
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Steve Nickolas]

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

On Sun, 26 Feb 2017, Michael Kjörling wrote:

> On 26 Feb 2017 12:15 -0500, from ron at ronnatalie.com (Ron Natalie):
>> Of course, he got run over by LINUX along the way.
>
> ...and even today, while the GNU userland sees reasonable use (just
> about every Linux distribution targetting the desktop or server niches
> use it, except for the few minimalistic ones that rely primarily on
> Busybox, so it's pretty hard to run Linux and not GNU), GNU Hurd lives
> a life of obscurity and few even know what it is, let alone knows
> anyone who uses it for anything even half-way serious.

I've thought of implementing a system using musl, clang and the Solaris 
userland on Linux just to prove that not all Linux is GNU/Linux. (As if 
Android doesn't always prove that.)

-uso.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Michael Kjörling]

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

On 26 Feb 2017 12:33 -0500, from usotsuki at buric.co (Steve Nickolas):
> On Sun, 26 Feb 2017, Michael Kjörling wrote:
>> ...so it's pretty hard to run Linux and not GNU...
> 
> I've thought of implementing a system using musl, clang and the
> Solaris userland on Linux just to prove that not all Linux is
> GNU/Linux. (As if Android doesn't always prove that.)

Yes, Android of course being the obvious counterexample to what I
wrote, which I thought of only after hitting send. Sorry.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Michael Kerpan]

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

Personally, I'd like to see something using the Heirloom Tools userspace.
Heirloom *roff, in particular, is miles ahead of GNU (especially when
dealing with fonts) while also being much lighter weight. The only bit of
GNU that I'd keep in my "ideal" OS would be GCC, which still produces
better output than Clang.

Mike

On Feb 26, 2017 12:33 PM, "Steve Nickolas" <usotsuki at buric.co> wrote:

> On Sun, 26 Feb 2017, Michael Kjörling wrote:
>
> On 26 Feb 2017 12:15 -0500, from ron at ronnatalie.com (Ron Natalie):
>>
>>> Of course, he got run over by LINUX along the way.
>>>
>>
>> ...and even today, while the GNU userland sees reasonable use (just
>> about every Linux distribution targetting the desktop or server niches
>> use it, except for the few minimalistic ones that rely primarily on
>> Busybox, so it's pretty hard to run Linux and not GNU), GNU Hurd lives
>> a life of obscurity and few even know what it is, let alone knows
>> anyone who uses it for anything even half-way serious.
>>
>
> I've thought of implementing a system using musl, clang and the Solaris
> userland on Linux just to prove that not all Linux is GNU/Linux. (As if
> Android doesn't always prove that.)
>
> -uso.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/c0ea68f3/attachment.html>

[TUHS] roff

[Larry McVoy]

On Sun, Feb 26, 2017 at 12:39:54PM -0500, Michael Kerpan wrote:
> Personally, I'd like to see something using the Heirloom Tools userspace.
> Heirloom *roff, in particular, is miles ahead of GNU (especially when
> dealing with fonts) while also being much lighter weight. 

What's better about the old roff?  The new roff has some pic enhancements
that I like.  I suspect the old roff includes grap, be nice to have that.

[TUHS] roff

[Ron Natalie]

> What's better about the old roff?  The new roff has some pic enhancements
that I like.  I suspect the old roff includes grap, be nice to have that.

It's utterly frozen.

[TUHS] roff

[Ron Natalie]

Amusingly someone sent me a document not that far back with a table in it.
I said "Did you use PIC and TBL with this?"    He admitted he did.    It had
the little tell tail stray overshoots on the vertical lines.   I would have
thought someone would have fixed that in the interim.

[TUHS] roff

[Dan Cross]

On Sun, Feb 26, 2017 at 2:36 PM, Ron Natalie <ron at ronnatalie.com> wrote:

> Amusingly someone sent me a document not that far back with a table in it.
> I said "Did you use PIC and TBL with this?"    He admitted he did.    It
> had
> the little tell tail stray overshoots on the vertical lines.   I would have
> thought someone would have fixed that in the interim.
>

When I was getting deployed to Afghanistan, we were given a little
laminated card with a "cheat sheet" of important bits of radio protocol on
it: how to call for a casualty evacuation, unexploded ordinance (I had to
use that one once, btw...), a thing called a MIST report that detailed
injuries, etc.

Anyway, something about the fonts and I *knew* it had been written using
troff. Of course, we didn't have the source, just the card...so I sat down
and recreated it. I printed a whole bunch out, laminated them and gave them
to my Marines to hang onto. I probably still have the PIC file laying
around my directory somewhere.

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

[TUHS] roff

[Michael Kerpan]

Heirloom roff, as maintained at
https://github.com/n-t-roff/heirloom-doctools, started with the code
released as part of OpenSolaris and added UTF-8 support, support for
various key bits added by groff, and then support for various modern
"smartfont" features, as well as the ability to use modern font files
directly rather than having to jump through various hoops. The whole
package is much lighter than groff while also having more (useful)
features and not having --very-long-options-like-this

Mike

On Sun, Feb 26, 2017 at 2:33 PM, Larry McVoy <lm at mcvoy.com> wrote:
> On Sun, Feb 26, 2017 at 12:39:54PM -0500, Michael Kerpan wrote:
>> Personally, I'd like to see something using the Heirloom Tools userspace.
>> Heirloom *roff, in particular, is miles ahead of GNU (especially when
>> dealing with fonts) while also being much lighter weight.
>
> What's better about the old roff?  The new roff has some pic enhancements
> that I like.  I suspect the old roff includes grap, be nice to have that.

[TUHS] roff

[Joerg Schilling]

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

Michael Kerpan <madcrow.maxwell at gmail.com> wrote:

> Heirloom roff, as maintained at
> https://github.com/n-t-roff/heirloom-doctools, started with the code

This is where troff used to be maintained until around summer 2011.

While most heirloom programs did only get attention for aprox. 3 months, troff, 
mailx and vi have been maintained for a longer time.

Then, since aprox. 6 years ago no traces to Gunnar Ritter have been seen in 
the net anymore.

Fortunately, mailx and troff now have new maintainers and can be found on 
github. 

troff now is at: https://github.com/n-t-roff/heirloom-doctools





Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] roff

[Joerg Schilling]

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

schily at schily.net (Joerg Schilling) wrote:

> Michael Kerpan <madcrow.maxwell at gmail.com> wrote:
>
> > Heirloom roff, as maintained at
> > https://github.com/n-t-roff/heirloom-doctools, started with the code
>
> This is where troff used to be maintained until around summer 2011.

Sorry for my fault, I thought I did see sourceforge here instead of github.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] roff

[Steffen Nurpmeso]

schily at schily.net (Joerg Schilling) wrote:
  ..
 |Fortunately, mailx and troff now have new maintainers and can be found on 
 |github. 

We, the former and i that is, are not on github.  I was shortly in
i think 2011, and i wanted to pay (because they paid (at least)
a developer, Jeff King, for working on Git), but they rejected my
clouts and only desired virtual clowds, but you know, the
low-payment sector is already flooded, in our local bank we not
longer than ten years ago had bank tellers, you know, that Arthur
Hailey Money-Changers story that i have read on the seventies,
these targets for Bonnie and Clyde, and other cicadas, now all
that robots instead, i think the tellers are now licking the
runway of Frankfurt airport speckless or something.  No.

--steffen

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Dave Horsfall]

On Sun, 26 Feb 2017, Noel Chiappa wrote:

>     > Another acronym is Esc Meta Alt Ctl Shift...
> 
> Good one!

Somewhere Out There (tm) is a web page full of EMACS acronyms.

> And there was a pretty funny fake Exxx error code - I think it was 
> "EMACS - Editor too big"?

"Editor too large"; it was in a list of fake error messages in a Usenix 
article.  Another was ENOTOBACCO - Read on empty pipe.

> I was never happy with the size of EMACS, and it had nothing to do with 
> the amount of memory resources used. That big a binary implies a very 
> large amount of source, and the more lines of code, the more places for 
> bugs... And it makes it harder to understand, for someone working on it 
> (to make a change/improvement).

I tried EMACS once (so I couldn't be accused of criticising it without 
trying it) and immediately ran back to the comfort of VI.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Lars Brinkhoff]

Dave Horsfall wrote:
> Somewhere Out There (tm) is a web page full of EMACS acronyms.

Or distributed with Emacs: etc/JOKES.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Dave Horsfall]

On Tue, 28 Feb 2017, Lars Brinkhoff wrote:

> > Somewhere Out There (tm) is a web page full of EMACS acronyms.
> 
> Or distributed with Emacs: etc/JOKES.

Wow - thanks!

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Jaap Akkerhuis]

> 
> On Feb 28, 2017, at 21:15, Dave Horsfall <dave at horsfall.org> wrote:
> 
> "Editor too large"; it was in a list of fake error messages in a Usenix
> article.  Another was ENOTOBACCO - Read on empty pipe.

ENOTOBACCO was the winner of the EUUG errno contest (I think Florence
meeting).  There were a couple of these contests.  There should be
a video somewhere where the jury is singing the winning entry of
the Atlanta one.  A description of the Nashville one can be found
at <http://www.qef.com/html/docs/egregious.pdf>.

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

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Michael Kjörling]

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

On 28 Feb 2017 21:40 +0100, from jaapna at xs4all.nl (Jaap Akkerhuis):
> ENOTOBACCO was the winner of the EUUG errno contest (I think Florence
> meeting).  There were a couple of these contests.

Here's one: https://www.gnu.org/fun/jokes/errno.2.html

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Un-released/internal/special UNIX versions/ports during theyears?

[jsteve]

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

I’ve read from early Microsoft employee’s that you had to learn to use vi to get vacation time, as they ran Xenix on all their backend stuff.  Although their first Xenix ads did mention it was available on the PDP-11, and other than one old post where someone mentioned that anytime there was a serious bug it was always in the Xenix portion.

It’s kind of funny that despite at one time being the highest installation by site count, Xenix has all but disappeared.  Not that OpenSERVER was either open or much of a good server.  And the only people I ever saw all that excited about UnixWare was telecom companies.

Sent from Mail for Windows 10

From: Arno Griffioen
Sent: Saturday, 25 February 2017 10:18 PM
To: tuhs at minnie.tuhs.org
Subject: [TUHS] Un-released/internal/special UNIX versions/ports during theyears?

Hi!

Some of the stories on here reminded me of the fact that there's also likely 
a whole boat-load of UNIX ports/variants in the past that were never released 
to customers or outside certain companies.

Not talking about UNIX versions that have become obsolete or which have
vanished by now like IRIX or the original Apple A/UX (now *that* was an 
interesting oddball though..) and such, but the ones that either died or 
failed or got cancelled during the product development process or were never 
intended to be released to the outside ar all.

Personally I came across one during some UNIX consultancy work at Commodore 
during the time that they were working on bringing out an SVR4 release for the 
Amiga (which they actually sold for some time)

Side-note.. Interestingly enough according to my contacts at that time inside 
CBM it was based on the much cheaper to license 3B2 SVR4 codebase and not the 
M68k codebase which explained some of the oddities and lack of M68k ABI 
compliance of the Amiga SVR4 release.. 

However.. 

It turned out that they had been running an SVRIII port on much older Amiga 
2000's with 68020 cards for some of their internal corporate networking and 
email, UUCP, etc. and was called 'AMIX' internally. But as far as I know it 
was never released to the public or external customers.

It was a fairly 'plain jane' SVRIII port with little specific 'Amiga' hardware 
bits supported but otherwise quite complete and pretty stable.

Worked quite well in the 4MB DRAM available on these cards. The later SVR4
didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!) 
16MB.

It was known 'outside' that something like this existed as the boot ROM's on 
the 68020 card had an 'AMIX' option but outside CBM few people really knew 
much about it.

It may have been used at the University of Lowell as they developed a TI34010 
based card that may already have had some support in this release.

Still..

This does make me wonder.. Does anyone else know of these kinds of special 
'snowflake' UNIX versions that never got out at various companies/insitutes?
(and can talk about it without violating a whole stack of NDA's ;) )

No special reason.. Just idle curiosity :)

Likely all these are gone forever anyway as prototypes and small run production 
devices and related software tends to get destroyed when companies go bust or 
get aquired.

							Bye, Arno.

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

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Al Kossow]

On 2/25/17 6:17 AM, Arno Griffioen wrote:
> the original Apple A/UX (now *that* was an 
> interesting oddball though..)

The original release was based on Unisoft UniPlus+, with some boot
resiliency added.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Jason Stevens]

There is that emulator shoebill which can run A/UX, even the 0.7 version which has the lower level unisoft sysv source.

But by the time they got around to version 3 it was an incredibly robust UNIX with a very simple UI, and by nature had access to an incredible amount of apps being source sysv compatible, and could run most sys6/7 apps, including SoftPC!

It's crazy that Apple never ported it to the PowerPC, as they basically had a next gen OS right under their nose the whole time, and ended up paying to port NeXT to the PowerPC, and doing the carbon shuffle to get apps...  But Apple has never been shy from doing things strange.

On February 26, 2017 3:02:20 AM GMT+08:00, Al Kossow <aek at bitsavers.org> wrote:
>
>
>On 2/25/17 6:17 AM, Arno Griffioen wrote:
>> the original Apple A/UX (now *that* was an 
>> interesting oddball though..)
>
>The original release was based on Unisoft UniPlus+, with some boot
>resiliency added.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/57c6b59e/attachment-0001.html>

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Gregg Levine]

Hello!
We (well most of us) all of us know about AIX. Well what about AIX/370?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Sat, Feb 25, 2017 at 9:17 AM, Arno Griffioen <arno.griffioen at ieee.org> wrote:
> Hi!
>
> Some of the stories on here reminded me of the fact that there's also likely
> a whole boat-load of UNIX ports/variants in the past that were never released
> to customers or outside certain companies.
>
> Not talking about UNIX versions that have become obsolete or which have
> vanished by now like IRIX or the original Apple A/UX (now *that* was an
> interesting oddball though..) and such, but the ones that either died or
> failed or got cancelled during the product development process or were never
> intended to be released to the outside ar all.
>
> Personally I came across one during some UNIX consultancy work at Commodore
> during the time that they were working on bringing out an SVR4 release for the
> Amiga (which they actually sold for some time)
>
> Side-note.. Interestingly enough according to my contacts at that time inside
> CBM it was based on the much cheaper to license 3B2 SVR4 codebase and not the
> M68k codebase which explained some of the oddities and lack of M68k ABI
> compliance of the Amiga SVR4 release..
>
> However..
>
> It turned out that they had been running an SVRIII port on much older Amiga
> 2000's with 68020 cards for some of their internal corporate networking and
> email, UUCP, etc. and was called 'AMIX' internally. But as far as I know it
> was never released to the public or external customers.
>
> It was a fairly 'plain jane' SVRIII port with little specific 'Amiga' hardware
> bits supported but otherwise quite complete and pretty stable.
>
> Worked quite well in the 4MB DRAM available on these cards. The later SVR4
> didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!)
> 16MB.
>
> It was known 'outside' that something like this existed as the boot ROM's on
> the 68020 card had an 'AMIX' option but outside CBM few people really knew
> much about it.
>
> It may have been used at the University of Lowell as they developed a TI34010
> based card that may already have had some support in this release.
>
> Still..
>
> This does make me wonder.. Does anyone else know of these kinds of special
> 'snowflake' UNIX versions that never got out at various companies/insitutes?
> (and can talk about it without violating a whole stack of NDA's ;) )
>
> No special reason.. Just idle curiosity :)
>
> Likely all these are gone forever anyway as prototypes and small run production
> devices and related software tends to get destroyed when companies go bust or
> get aquired.
>
>                                                         Bye, Arno.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[arnold]

Gregg Levine <gregg.drwho8 at gmail.com> wrote:

> Hello!
> We (well most of us) all of us know about AIX. Well what about AIX/370?

What about it?

It definitely existed.  It and AIX for the PC were similar but different
from AIX on the RS/6000...

I never saw it personally, but it was orderable.

Arnold

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Ronald Natalie]

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


> On Feb 28, 2017, at 10:15 PM, Gregg Levine <gregg.drwho8 at gmail.com> wrote:
> 
> Hello!
> We (well most of us) all of us know about AIX. Well what about AIX/370?
> ——

AIX/370 was a real product.     One of the ones that I don’t ever think saw the light of day was the i860 AIX port.   IBM made two i860 add-in cards for the PS/2.   The single processor version was called the Wizard and there was a 4 processor version with an integral frame buffer called the W4.     We ported AIX to both.    The i860 version actually had more in common with the 370 version than it did with the 386.     All of these AIX versions came from the same source code and used the IBM TCF to allow you to transparently run executables across nodes in the cluster.     The only AIX that didn’t play was the completely independent (and in my opinion somewhat brain damaged) IBM/RT UNIX.    If there was a TCF-based RT kernel, I never saw it, even inside the IBM labs.

Speaking of odd job control mechanisms.   The 386 side had a device that multiplexed the PS/2 console into multiple streams called the “High Function Terminal.”   When we wrote the virtual console for the Wizard/W4 add in card, we called it the “Low Function Terminal."

[TUHS] Un-released/internal/special UNIX versions/ports duringthe years?

[jsteve]

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

I had never hear of an i860 board from IBM, but a little searching, and it almost looks like it was going to be a thing.

NUMBER     290-817
DATE       901218
TYPE       Programming
TITLE      INTEL OS/2 AND AIX I860 SOFTWARE DEVELOPMENT TOOLS FOR C AND FORTRAN
ABSTRACT  Today, IBM announces C and FORTRAN compiler support for the
   PS/2 (R) Wizard Adapter running under both AIX (R) PS/2 and OS/2 (R)
   operating systems.
<           hundreds of lines of information deleted          >
TECHINFO   TECHNICAL INFORMATION
   SPECIFIED OPERATING ENVIRONMENT
v  MACHINE REQUIREMENTS:
|  o   The Intel OS/2 and AIX i860 Software Development Tools for C and
|      FORTRAN require one of the following PS/2 system units:
|      -   PS/2 Model 70
|      -   PS/2 Model P75*
|      -   PS/2 Model 80
|      -   PS/2 Model 90 XP*
|      -   PS/2 Model 95 XP*
|             The Model P70 is not supported.
====>  *  These models are not currently supported by AIX PS/2.
          Therefore, the PS/2 Wizard Adapter will operate only with IBM
          OS/2 on these models.


Or later something like this:

IBM architecture - RT
IBM architecture - RS/6000
IBM architecture - S/370
Intel architecture - i386

(rumors of)
Intel architecture - i860	(Wizard PS/2 cardset with 4xi860)
whatever comes out of Steve Chen's supercomputer work

Of course, with IBM not licensing AIX source to anyone, these are only
IBM machines, but that is not the same as AIX being a non-portable OS.

Rumors are that IBM's customers are pressing very hard for source
licenses and that someday such licenses will be available.  Whether
that would lead to ports to other machines, I can't predict.


Very interesting!

Sent from Mail for Windows 10

From: Ronald Natalie
Sent: Wednesday, 1 March 2017 3:45 PM
To: Gregg Levine
Cc: Tuhs
Subject: Re: [TUHS] Un-released/internal/special UNIX versions/ports duringthe years?


> On Feb 28, 2017, at 10:15 PM, Gregg Levine <gregg.drwho8 at gmail.com> wrote:
> 
> Hello!
> We (well most of us) all of us know about AIX. Well what about AIX/370?
> ——

AIX/370 was a real product.     One of the ones that I don’t ever think saw the light of day was the i860 AIX port.   IBM made two i860 add-in cards for the PS/2.   The single processor version was called the Wizard and there was a 4 processor version with an integral frame buffer called the W4.     We ported AIX to both.    The i860 version actually had more in common with the 370 version than it did with the 386.     All of these AIX versions came from the same source code and used the IBM TCF to allow you to transparently run executables across nodes in the cluster.     The only AIX that didn’t play was the completely independent (and in my opinion somewhat brain damaged) IBM/RT UNIX.    If there was a TCF-based RT kernel, I never saw it, even inside the IBM labs.

Speaking of odd job control mechanisms.   The 386 side had a device that multiplexed the PS/2 console into multiple streams called the “High Function Terminal.”   When we wrote the virtual console for the Wizard/W4 add in card, we called it the “Low Function Terminal."

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

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Dan Cross]

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

On Wed, Mar 1, 2017 at 2:45 AM, Ronald Natalie <ron at ronnatalie.com> wrote:

>
> > On Feb 28, 2017, at 10:15 PM, Gregg Levine <gregg.drwho8 at gmail.com>
> wrote:
> >
> > Hello!
> > We (well most of us) all of us know about AIX. Well what about AIX/370?
> > ——
>
> AIX/370 was a real product.     One of the ones that I don’t ever think
> saw the light of day was the i860 AIX port.   IBM made two i860 add-in
> cards for the PS/2.   The single processor version was called the Wizard
> and there was a 4 processor version with an integral frame buffer called
> the W4.     We ported AIX to both.    The i860 version actually had more in
> common with the 370 version than it did with the 386.     All of these AIX
> versions came from the same source code and used the IBM TCF to allow you
> to transparently run executables across nodes in the cluster.     The only
> AIX that didn’t play was the completely independent (and in my opinion
> somewhat brain damaged) IBM/RT UNIX.


We had RTs where I was. By the time I came on the scene, they were being
decommissioned in favor of RS/6k hardware (arguably, the RT was pretty
low-powered even for its day), so the students were running around grabbing
them and playing with them. We ran AOS on ours, which was a more-or-less
straight port of 4.3BSD+NFS (maybe they started with Tahoe? I don't know),
but IBM seemed to want to push AIX with them. The RT was my first exposure
to "real" Unix source code.

What was interesting to me was all of the #ifdef's in the source that made
it clear that someone at IBM had obviously tried to port 4.3 to the 370. I
don't think that ever saw the light of day, but there were definitely
vestiges of it in the kernel.

I had understood was that AIX/370 was actually OSF/1 based and totally
separate from AIX 2.x (on the RT) and AIX 3.x (on the RS/6k)? From what you
wrote, it sounds like that wasn't quite right.

If there was a TCF-based RT kernel, I never saw it, even inside the IBM
> labs.
>
> Speaking of odd job control mechanisms.   The 386 side had a device that
> multiplexed the PS/2 console into multiple streams called the “High
> Function Terminal.”   When we wrote the virtual console for the Wizard/W4
> add in card, we called it the “Low Function Terminal."


Did the HFT survive into the RS/6k? I seem to recall hearing about that.
Perhaps it was an option on the RT, or somehow could be used with the
"crossbow" card on the 6152?

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

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Nemo]

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

On 1 March 2017 at 02:45, Ronald Natalie <ron at ronnatalie.com> wrote (in part):
[...]
> The only AIX that didn’t play was the completely independent (and in my
> opinion somewhat brain damaged) IBM/RT UNIX.

No wonder, given what they did to the poor chip it ran on.  #6-)

N.

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Clem Cole]

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

On Wed, Mar 1, 2017 at 2:45 AM, Ronald Natalie <ron at ronnatalie.com> wrote:

> AIX/370 was a real product.

​Indeed​ it was.




>   All of these AIX versions came from the same source code and used the
> IBM TCF to allow you to transparently run executables across nodes in the
> cluster.

​Exactly right.   TCF - Transparent Computing Facility -- No mean trick...
​you can mix PS/2 and 370 in the cluster, so root on desk allowed me root
on the mainframe too.   What was cool was that the TCF will look at the
executable and find the proper CPU.   The big mistake was that that node id
was stored in a single 32 bit word and assigned per bit, which was a
scaling issues.

I was at Locus Computing Corp (aka LCC or just "Locus"), who developed AIX
for IBM under contract and TCF was part of it.  The direct result of the The
LOCUS Distributed System Architecture
<https://www.amazon.com/Distributed-System-Architecture-Computer-Systems/dp/0262517191/ref=sr_1_1?s=books&ie=UTF8&qid=1488391384&sr=1-1&refinements=p_27%3AGerald+J.+Popek>
from
UCLA.  The book actually describes much of the AIX/370 work, but starts
with the original UCLA work.  I did not work on the IBM project, although a
number of my peers did.  I was higher to help developed TNC - Transparent
Network Computing, which is was used in Intel's Paragon and DEC's
TruClusters and a never shipped HP Cluster Product. Many of the same ideas
but we wanted a separate team that never saw the IBM code so there could
never be any concern about ownership.  The architects like me and Roman,
were allowed to talk to the AIX architects, such as Bruce; but we keep
separate development environments at separate sites.    After the IBM work
ended, all of the Locus  distributed system folks the struct around went to
work on TNC and the technology go sold off and licensed.   What was
interesting is that TNC was open'ed sourced after the Compaq/HP mergers and
put into Linux but I've forgotten the URL (I'll search and follow up).

It's a real shame it never went anywhere.   It was a very, very cool.




>      The only AIX that didn’t play was the completely independent (and in
> my opinion somewhat brain damaged) IBM/RT UNIX.    If there was a TCF-based
> RT kernel, I never saw it, even inside the IBM labs.

​That was IBM politics.   LCC has the contract for the original AIX port to
the 370.   When the RT was developed, the Austin team was ramped up.   One
of our members of the TUHS list who is remaining silent I see is not saying
why but I know was there ;-) and might  known the actual politics, I never
did.   But when the AIX/RT port was forked, they started with AIX/370 code
base and removed the TCF code.   But LCC still had the AIX/370 contract
from Enterprise system group to maintain AIX/370.   And also, Locus had the
contract from Entry Systems, who all they wanted TCF.   So AIX/386 and
AIX/370 as Ron points out were one code base, one dev team (at LCC in
California).

Dan Cross said:  "I had understood was that AIX/370 was actually OSF/1
based"

It maybe that by the end, the user space was based on the OSF/1 user space
code.  That was true for HP and DEC also.   But I can definitely state
AIX/370 and AIX/386 were one set of source trees and all of was done by
Locus Computing Corporation certainly through the mid 1990s.

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

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Jason Stevens]

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

Slightly off or on topic, but since you seem to know, and I've never seen aix 370 in the eild, did it require VM?  Did it take advantage of SNA, and allow front ends, along with SNA gateways and 3270's?

Or was it more of a hosted TCP/IP accessable system?

On March 2, 2017 2:17:00 AM GMT+08:00, Clem Cole <clemc at ccc.com> wrote:
>
>On Wed, Mar 1, 2017 at 2:45 AM, Ronald Natalie < ron at ronnatalie.com
><mailto:ron at ronnatalie.com> > wrote:
>
>
>AIX/370 was a real product.  
>
>​Indeed​ it was.
>
>
> 
>
>  All of these AIX versions came from the same source code and used the
>IBM TCF to allow you to transparently run executables across nodes in
>the cluster.
>
>​Exactly right.   TCF - Transparent Computing Facility -- No mean
>trick... ​you can mix PS/2 and 370 in the cluster, so root on desk
>allowed me root on the mainframe too.   What was cool was that the TCF
>will look at the executable and find the proper CPU.   The big mistake
>was that that node id was stored in a single 32 bit word and assigned
>per bit, which was a scaling issues.
>
>
>I was at Locus Computing Corp (aka LCC or just "Locus"), who developed
>AIX for IBM under contract and TCF was part of it.  The direct result
>of
>the The LOCUS Distributed System Architecture
><https://www.amazon.com/Distributed-System-Architecture-Computer-Systems
>/dp/0262517191/ref=sr_1_1?s=books&ie=UTF8&qid=1488391384&sr=1-1&refineme
>nts=p_27%3AGerald+J.+Popek>  from UCLA.  The book actually describes
>much of the AIX/370 work, but starts with the original UCLA work.  I
>did
>not work on the IBM project, although a number of my peers did.  I was
>higher to help developed TNC - Transparent Network Computing, which is
>was used in Intel's Paragon and DEC's TruClusters and a never shipped
>HP
>Cluster Product. Many of the same ideas but we wanted a separate team
>that never saw the IBM code so there could never be any concern about
>ownership.  The architects like me and Roman, were allowed to talk to
>the AIX architects, such as Bruce; but we keep separate development
>environments at separate sites.    After the IBM work ended, all of the
>Locus  distributed system folks the struct around went to work on TNC
>and the technology go sold off and licensed.   What was interesting is
>that TNC was open'ed sourced after the Compaq/HP mergers and put into
>Linux but I've forgotten the URL (I'll search and follow up).
>
>
>It's a real shame it never went anywhere.   It was a very, very cool.
>
>
> 
>
>     The only AIX that didn’t play was the completely independent (and
>in my opinion somewhat brain damaged) IBM/RT UNIX.    If there was a
>TCF-based RT kernel, I never saw it, even inside the IBM labs.
>
>​That was IBM politics.   LCC has the contract for the original AIX
>port
>to the 370.   When the RT was developed, the Austin team was ramped up.
>One of our members of the TUHS list who is remaining silent I see is
>not
>saying why but I know was there ;-) and might  known the actual
>politics, I never did.   But when the AIX/RT port was forked, they
>started with AIX/370 code base and removed the TCF code.   But LCC
>still
>had the AIX/370 contract from Enterprise system group to maintain
>AIX/370.   And also, Locus had the contract from Entry Systems, who all
>they wanted TCF.   So AIX/386 and AIX/370 as Ron points out were one
>code base, one dev team (at LCC in California).
>
>Dan Cross said:  "I had understood was that AIX/370 was actually OSF/1
>based"
>
>
>It maybe that by the end, the user space was based on the OSF/1 user
>space code.  That was true for HP and DEC also.   But I can definitely
>state AIX/370 and AIX/386 were one set of source trees and all of was
>done by Locus Computing Corporation certainly through the mid 1990s.
>
>
>Clem

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

[TUHS] Un-released/internal/special UNIX versions/ports during the years?

[Gregg Levine]

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

Hello!
Well before it was withdrawn from marketing, it played in a big pool
Namely the mainframes at one of the universities in Norway. And I got
this from a VMer I who is best known for writing the pipelines stuff,
And sadly that was its only customer.

By contrast AIX for RS/6000 gang and its ancestors were well taken
care of and its still available.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Wed, Mar 1, 2017 at 1:17 PM, Clem Cole <clemc at ccc.com> wrote:
>
> On Wed, Mar 1, 2017 at 2:45 AM, Ronald Natalie <ron at ronnatalie.com> wrote:
>>
>> AIX/370 was a real product.
>
> Indeed it was.
>
>
>
>>
>>   All of these AIX versions came from the same source code and used the
>> IBM TCF to allow you to transparently run executables across nodes in the
>> cluster.
>
> Exactly right.   TCF - Transparent Computing Facility -- No mean trick...
> you can mix PS/2 and 370 in the cluster, so root on desk allowed me root on
> the mainframe too.   What was cool was that the TCF will look at the
> executable and find the proper CPU.   The big mistake was that that node id
> was stored in a single 32 bit word and assigned per bit, which was a scaling
> issues.
>
> I was at Locus Computing Corp (aka LCC or just "Locus"), who developed AIX
> for IBM under contract and TCF was part of it.  The direct result of the The
> LOCUS Distributed System Architecture from UCLA.  The book actually
> describes much of the AIX/370 work, but starts with the original UCLA work.
> I did not work on the IBM project, although a number of my peers did.  I was
> higher to help developed TNC - Transparent Network Computing, which is was
> used in Intel's Paragon and DEC's TruClusters and a never shipped HP Cluster
> Product. Many of the same ideas but we wanted a separate team that never saw
> the IBM code so there could never be any concern about ownership.  The
> architects like me and Roman, were allowed to talk to the AIX architects,
> such as Bruce; but we keep separate development environments at separate
> sites.    After the IBM work ended, all of the Locus  distributed system
> folks the struct around went to work on TNC and the technology go sold off
> and licensed.   What was interesting is that TNC was open'ed sourced after
> the Compaq/HP mergers and put into Linux but I've forgotten the URL (I'll
> search and follow up).
>
> It's a real shame it never went anywhere.   It was a very, very cool.
>
>
>
>>
>>      The only AIX that didn’t play was the completely independent (and in
>> my opinion somewhat brain damaged) IBM/RT UNIX.    If there was a TCF-based
>> RT kernel, I never saw it, even inside the IBM labs.
>
> That was IBM politics.   LCC has the contract for the original AIX port to
> the 370.   When the RT was developed, the Austin team was ramped up.   One
> of our members of the TUHS list who is remaining silent I see is not saying
> why but I know was there ;-) and might  known the actual politics, I never
> did.   But when the AIX/RT port was forked, they started with AIX/370 code
> base and removed the TCF code.   But LCC still had the AIX/370 contract from
> Enterprise system group to maintain AIX/370.   And also, Locus had the
> contract from Entry Systems, who all they wanted TCF.   So AIX/386 and
> AIX/370 as Ron points out were one code base, one dev team (at LCC in
> California).
>
> Dan Cross said:  "I had understood was that AIX/370 was actually OSF/1
> based"
>
> It maybe that by the end, the user space was based on the OSF/1 user space
> code.  That was true for HP and DEC also.   But I can definitely state
> AIX/370 and AIX/386 were one set of source trees and all of was done by
> Locus Computing Corporation certainly through the mid 1990s.
>
> Clem
>
>