I spotted this when glancing through a book catalogue; well, with a title
like that how could I miss it?
Subtitled "How 26 Lines of Code Changed the World", edited by Torie Bosch
and illustrated by Kelly Chudler (can't say that I've heard of them).
Summary:
``Programming is behind so much of life today, and this book draws together
a group of distinguished thinkers and technologists to reveal the
stories and people behind the computer coding that shapes our
world. From how university's [sic] databases were set up to
recognise only two genders to the first computer worm and the
first pop-up ad, the diverse topics reveal the consequences of
historical decisions and their long-lasting, profound implications.
Pb $34.99''
Lines of code, eh? :-)
Abbey's Bookshop: www.abbeys.com.au
Disclaimer: I have no connection with them, but I'll likely buy it.
-- Dave
Clem Cole:
Yep -- but not surprising. There were a bunch of folks at DG that had
worked on a single-level store system (Project Fountain-Head) that had
failed [some of that story is described in Kidder's book].
====
Are you sure? I thought Fountainhead was a Rand project.
Norman Wilson
Toronto ON
PS: if you don't get it, consider yourself fortunate.
>> 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
