>> To be honest, I've forgotten many (most) of the details. But that sounds
>> about right. As I remember it, it was like SunOS. The key point was that
>> the kernel only had one view of the memory system period, no FS
>> buffer cache etc...which was a departure from many of the traditional UNIX
>> implementations. IIRC they did not support BSD's mmap -- but check the
> It sounds like they could have supported mmap() easily. I'd love to see
> this kernel, it sounds to me like it was SunOS with nicely done SMP
> support. The guy that said he'd never seen anything like it before or
> since, just makes me want to see it more.
"One view of the memory, period." That describes Multics.
Doug
This is what Scott Lee, who ran the Eclipse at Georgia Tech
recalls. He has given permission for me to forward it, with
the caveat that it was long ago and that "memories are malleable".
Arnold
> Date: Mon, 14 Nov 2022 05:35:51 -0500
> Subject: Re: [TUHS] DG UNIX History
> From: scott(a)thelees.org
> To: arnold(a)skeeve.com
>
> > I'm pretty sure that DG never ported DG-UX to the Nova. There was
> > a native port to the Eclipse (32 bit). There was also a Eunice-style
> > Unix environment that sat on top of their native OS, whatever it was
> > called.
>
> Yeh, that was an MV-10000 that we received. As I remember it, we also got
> a copy of DG-UX, which was a port of SYS Vr2, not r3 as mentioned. I
> think that it may have also had a directory with UCB versions of a bunch
> of the utilities ported over so you could run either SysV tools or UCB
> tools.
>
> LeBlanc was going to use it to teach ADA, so I was building some tools to
> create/maintain user accounts, but I believe that I left just before they
> were actually getting around to that.
>
> I was also playing with it on the side, when no one else was using it, to
> build a small OS on it. I found that it followed a lot of the Nova
> behavior, so I figured out how to write code onto a tape and bootstrap it
> into the machine. Wrote a tape driver and a console driver and was
> working on a disk driver. Targeting putting a small OS on it.
>
> Wow... I had almost forgotten that it even existed until I saw this.
>
> Enjoy,
> Scott
This recent activity on the simh mailing list WRT to DG Nova and
Ecpilse got me wondering. At Locus in the 80s and 90s, we did a lot of
work with DG and DG-UX with their later MP-based ports using commercially
available microprocessors (which I have reported was a very nicely done
system, easy to work on, the locks tended to scale well, e*tc*.).
But I am trying to remember if C or UNIX was on a Nova or an Eclipse. This
could be my failed memory, given that so many people ported V7 in the late
1970s (the infamous 'NUIX' bug from the Series/1 port probably being my
favorite tale). So to the hive mind, did anyone (DG themselves or a
University) ever build 16 or 32-bit tools for the DG architectures and do a
UNIX port, and if so, does anyone know what became of those efforts? Is
this something that needs to be in the TUHS archives also?
Clem
ᐧ
I’ve only recently stumbled across this paper.
It gives the answer to one question I’ve had:
Why did Linux become more popular than everything that came before it?
There were surprises.
The “Dot Boom” then “Dot Bust” along with Y2K.
Microsoft developed an architecture, Active Directory, designed to support Enterprise scale deployments.
Everything Good in A.D. is Old (LDAP, Kerberos, DNS)
everything badly done is New (replicated DB’s & ???).
Other surprises is the rise of “Internet Scale” datacentres, Social Media and Smartphones & Tablets.
All of which are dominated by Linux or Unix derived solutions.
And Virtual Machines on Intel.
IA-64 was in the far future :(
And ARM CPU’s made a big comeback.
==========
The Sourceware Operating System Proposal
9 November 1993
Revision: 1.8
<https://www.landley.net/history/mirror/unix/srcos.html>
==========
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
I remember being told back in the 1980s that vi would set the terminal
to "cooked mode" when vi was in "insert mode", so as to reduce expensive
context switching for each character typed. Only vi's "command mode"
would set the terminal to "raw mode" so as to provide immediate feedback
on each (command) character typed. This would be a clever system
performance optimization, and would also explain designing vi around
distinct insert and command modes.
However, I can't find such evidence even as far back as BSD 1. It seems
that in insert mode ESC was processed like any other character.
https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Develop…
Cooked mode was only entered when scrolling in order to receive interrupts.
https://github.com/dspinellis/unix-history-repo/blob/BSD-1-Snapshot-Develop…
Also, for this scheme to work ESC would need to be mapped to an
interrupt key, so as to allow exiting the cooked mode through the
corresponding signal handler. Again, grepping for ESC, did not show me
any such code.
I also remember being told that this optimization was what allowed
twenty students to concurrently perform interactive editing on a VAX
11/780 (running 4.2BSD and then 4.3BSD), and that Emacs was not provided
to students because it was always operating in raw mode.
Was I misled? Was there perhaps a hacked version of vi that worked in
this way?
-Diomidis
> From: Diomidis Spinellis
> I remember being told back in the 1980s that vi would set the terminal
> to "cooked mode" when vi was in "insert mode", so as to reduce expensive
> context switching for each character typed.
> ...
> However, I can't find such evidence even as far back as BSD 1.
Maybe you're thinking of Multics Emacs, which had such a capability:
https://multicians.org/mepap.html
Noel
