In 2007 I started entering the contents of Eric Levenez’s “Unix History” diagram into “dot” format to use with Graphviz.
It stalled when I was unable to create a diagram I really liked.
My recollection is that I talked with Warren about encoding this data and creating diagrams.
He compiled the TUHS “Unix Tree”, presumably now the definitive resource, but I haven’t see a diagram linked from there.
There’s the github “Unix History” project by TUHS list folk <https://github.com/dspinellis/unix-history-repo>
I didn’t research producing timelines & relationships automatically from git:
this would be a solid solution, if the Repo was considered as permanent as the TUHS site.
The “Linux Distribution Timeline” is based on a tool, gnuclad, that takes CSV files and 'computes a cladogram’ in SVG. conversion to PNG is via ImageMagick’s “convert”.
By default, timelines are produced ‘left to right’, with claimed ‘right to left’, ’top to bottom’ and ‘bottom to top’ formats - which I haven’t tested.
The CSV file can include links which are built into clickable points in the final image, at least for SVG, unsure of PNG.
A concern that I have is the creation of the CSV file from Distrowatch is opaque. Possibly built by hand. New diagrams are uploaded 2-3 times a year.
The Levenez "fishbone" diagram doesn’t seem to be updated with Warner Losh’s 2020 “Hidden Early History”.
Clem Cole’s Big Block diagram shows “low-res” diagrams are also very useful, eliminating distracting detail when appropriate.
Groklaw from 2004-2009 tried to collect information about the Unix/Linux Timelines, but the site is gone now & Wayback machine hasn’t picked up many of the detail / comments page.
I’ve no contact with PJ & whoever runs Groklaw now.
Would that data collection contain anything more than TUHS, as it does try to include both Linux and Unix?
Any suggestions?
Something extra in the Linux Distro Tree is a notation for people moving between projects and tracking forks. Unsure how that’s accomplished, and not sure how important that is for Unixes.
TUHS is “Early Unix”, not about Linux.
However, some degree of compatibility between Unix & Linux Timeline diagrams might be useful for others if they ever try to join multiple trees.
If a timeline / relationship table is constructed, designing it to be somewhat compatible will help future people.
I’m not sure about tracking the many descendants of BSD. Wikipedia has a list without a timeline . <https://en.wikipedia.org/wiki/List_of_BSD_operating_systems>
Someone may already be being doing this somewhere, I didn’t look.
Don’t think modern descendants of BSD should be tracked by a Unix Heritage Society, has to be a boundary somewhere.
regards
steve jenkin
============
Some Questions:
1. Is there any benefit in developing a canonical “Unix Timeline” dataset containing the relationships, allowing programatic conversion to diagrams? There might be better tools in the future.
I’d favour tab-separated text files, because they can be read / written by Spreadsheets and converted to CSV.
Warren’s solution of tables & pages is good: there’s simply too much information & complexity to capture in simple file formats
The gnuclad solution of providing “Clickable Links” is useful, if like TUHS, the pages are well maintained.
2. How to cater for:
- adding extra-fine detail for segments of the timeline (Warner Losh)
- ‘zooming out’ and providing an overview (Clem Cole)
- some sort of compatibility with known tables, like Linux Distro Timeline
3. No simple representation can, or should try, to be “all things to all people”, there’s too much detail and too many events occurred.
Is there a useful subset of detail that can be captured in a simple table?
There may be useful subsets of the Unix Timeline that show more or less detail,
To support programatic zoom In/Out, an indent or level descriptor is required in the table.
Does anyone have a good data model for that?
============
Warner Losh, "Hidden Early History of Unix”, Fosdem 2020
-> "Standard History of Unix, in 3 slides”
graphviz, coloured names, landscape format [small]
“Simplified family tree”
4th Edition Family Tree
6th Edition Family Tree
7th Edition Family Tree
Clem Cole, UNIX, Linux and BSD, USENIX 2009, reexamining "A Short UNIX History”, 2000 talk
-> "A UNIX Family History 1st 25 Yrs” [69-93]
graphviz ?, landscape, coloured, triangle symbols, thin lines & arrows
-> Simplified Linux Family Tree, circa ’09
graphviz ?, landscape, coloured, blocks + text, short thick lines & arrows
============
TUHS, The Unix Tree
No diagrams, tarball with all content
<https://www.tuhs.org/cgi-bin/utree.pl>
Éric Lévénez’s, "UNIX History”
landscape format [very wide], lines & arrows, hand drawn, no source
<https://www.levenez.com/unix/>
David du Colombier, Unix Diagram
portrait format, graphviz, source
<http://www.unix-diagram.org>
Linux Timeline, Fabio Loli et al
landscape format, gnuclad, source (CSV + links to <https://distroware.gitlab.io/>)
uses ‘curved’ lines, can be changed
<https://github.com/FabioLolix/LinuxTimeline>
Images: SVG, PNG
<https://github.com/FabioLolix/LinuxTimeline/releases/tag/v21.10>
Grokline, UNIX TIMELINE, 2004-2009 [dead site]
Lists by Date, Vendor, Product
detail pages not archived
<https://web.archive.org/web/20091217070631/http://www.grokline.net/time_ind…>
============
--
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
Today I came across an article about the MGR window system for Unix:
https://hack.org/mc/mgr/
One thing that interested me was a note that some versions worked on the
Macintosh:
> The window system ran on many different hardware platforms, at least
> these: Sun 3/xx workstations running SunOS, which was the the original
> development platform, Sun SPARCstations (SunOS and then ported by me to
> Solaris), Intel x86 based PCs (Coherent, Minix, FreeBSD or Linux),
> Atari ST (under MiNT), AT&T UnixPC (SysV) and the Macintosh.
As the owner of a Macintosh Plus, I think it would be a very interesting
thing to experiment with, but I haven't had much luck finding any more
information about it.
Does anyone know more about MGR, particularly on the Mac? That page has
the source for MGR 0.69, but there's no mention of the Macintosh in it
(aside from comments about how it was supported on older versions...)
John
I know something!
On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote:
> > o why CTRL/S and CTRL/Q are used for flow control in a shell command
> > line session
> >
> Also would be happy to know.
https://en.wikipedia.org/wiki/Software_flow_control
But I don't know the answer to Ctrl-D. :( And also the bus error
and maybe the segmentation fault if it hasn't to do with a segment
register.
Matthias
--
When You Find Out Your Normal Daily Lifestyle Is Called Quarantine
> I heard that the IBM 709
> series had 36 bit words because Arthur Samuel,
> then at IBM, needed 32 bits to identify the playable squares on a
> checkerboard, plus some bits for color and kinged
To be precise, Samuel's checkers program was written for
the 701, which originated the architecture that the 709 inherited.
Note that IBM punched cards had 72 data columns plus 8
columns typically dedicated to sequence numbers. 700-series
machines supported binary IO encoded two words per row, 12
rows per card--a perfect fit to established technology. (I do
not know whether the fit was deliberate or accidental.)
As to where the byte came from, it was christened for the IBM
Stretch, aka 7020. The machine was bit-addressed and the width
of a byte was variable. Multidimensional arrays of packed bytes
could be streamed at blinding speeds. Eight bits, which synced
well with the 7020's 64-bit words, was standardized in the 360
series. The term "byte" was not used in connection with
700-series machines.
Doug
Hello,
I have on my hands many images of tapes that seems to have been written
by various implementaions of dump. I see the magic numbers 60011 and
60012 in little and big endian at offsets 18 (16-bit version?) and 24
(32-bit version?). I don't know the dating of the tapes, but around
1980 would be a reasonable guess.
Are there some easy to use (ready to run on a modern Unix) tools to
extract files from such tape files?
I'm not looking to restore a file system on disk, just extract the
files.
Hello all,
I've recently been improving the AT&T/Teletype DMD 5620 simulator I wrote a few years ago. It can now run either the 8;7;3 or 8;7;5 firmware. It also now supports executing a local shell or connecting directly to a physical or virtual tty device. It runs natively on Linux or macOS with X11 or Wayland, but I would love help creating a Windows version if you're a Windows programmer (I am an occasional Windows user, but I am not at all knowledgeable about Windows programming).
Full details are available here: https://loomcom.com/3b2/dmd5620_emulator.html
The source code is here: https://github.com/sethm/dmd_gtk
Many thanks go to my friend Sark (@crtdude on Twitter) for tracking down the 8;7;3 firmware and dumping it for me. I'd also like to thank Mike Haertel for helping find bugs, providing feedback, and inspiring me to get it working with Research Unix in addition to SVR3.
Feedback, bug reports, and pull requests are all welcome!
-Seth
--
Seth Morabito
Poulsbo, WA
web(a)loomcom.com
Anecdote prompted by the advent of Burroughs in this thread:
At the 1968 NATO conference on Software Engineering, the discussion
turned to language design strategies. I noted that the design of Algol
68, for example, presupposed a word-based machine, whereupon Burroughs
architect Bob Barton brought the house down with the remark, "In the
beginning was the Word, all right--but it was not a fixed number of
bits!"
[Algol 68's presupposition is visible in declarations like "long long
long ... int". An implementation need support only a limited number of
"longs", but each supported variety must have a definite maximum
value, which is returned by an "environment enquiry" function. For
amusement, consider the natural idea of implementing the longest
variety with bignums.]
Doug
The error was introduced on 13 September 2005, by an anonymous user from an IP address allocated to Web Perception, a Californian ISP, and (currently) geolocated to Sonoma. The change comment was:
Changes - 386BSD factual errors corrected, potentially libelous statements removed, links updated, refocus on 386BSD history, authority-386BSD authors, published works, DMR refs
The same IP address was used for a series of edits over 2005-2006, to topics including 386BSD, Lynne Jolitz, William Jolitz, and Radiocarbon Dating.
I imagine it was simply a mistake.
d
> On 10 Sep 2022, at 12:26, Grant Taylor via COFF <coff(a)tuhs.org> wrote:
>
> On 9/9/22 8:05 PM, Greg 'groggy' Lehey wrote:
>> Done.
>
> Thank you!
>
>> Do you have an idea about how this error crept in?
>
> No, I do not.
>
> I came to this article after reading about the DDJ DVD archive on the geeks mailing list. I was sensitive to the emails about DDJ because I've been looking to acquire the issues (or at least articles) with the Porting Unix to the 386 articles in them.
>
> Now I have them! :-D
>
>
>
> --
> Grant. . . .
> unix || die
>
https://www.timeanddate.com/on-this-day/september/9
``Unix time or Unix epoch, POSIX time or Unix timestamp, is a time system
that measures the number of seconds since midnight UTC of January 1, 1970,
not counting leap seconds. At 01:46:40 UTC on September 9, 2001, Unix time
reached the billionth second timestamp.''
Hard to believe that it was that long ago...
-- Dave
Paul Winalski and Bakul Shah commented on bit addressable machines
on the TUHS list recently. From Blaauw and Brooks' excellent
Computer Architecture book
http://www.math.utah.edu/pub/tex/bib/master.html#Blaauw:1997:CAC
on page 98, I find
>> ...
>> The earliest computer with bit resolution is the [IBM 7030] Stretch.
>> The Burroughs B1700 (1972) and CDC STAR100 (1973) are later examples.
>>
>> Bit resolution is costly in format space, since it uses a maximum
>> number of bits for address and length specification. Sharpening
>> resolution from the byte to the bit costs the same as increasing
>> address-space size eight-fold.
>>
>> Since almost all storage realizations are organized as matrices,
>> bit resolution is also expensive in time or equipment.
>> ...
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------