> The wikipedia description
> <http://en.wikipedia.org/wiki/CAT_(phototypesetter)>
> seems pretty accurate although I have never seen the beast myself.
I can confirm the wikipedia description. At Bell Labs, however, we
did not use paper tape input. As soon as the machine arrived, Joe
Ossanna bypassed the tape reader so the C/A/T could be driven
directly from the PDP-11. The manufacturer was astonished.
The only operational difficulty we had was with the separate
developer. If you didn't hand feed the end of the paper perfectly
straight into that machine, the paper would tear. Joe Condon
fixed that by arranging for the canister to sit on rollers so
it could give when the paper pulled sideways.
The first technical paper that came off the C/A/T drew a query
from the journal editor, who'd never seen a phototypeset
manuscript before: had it been published elsewhere?
Doug
> Didn't the BSTJ get phototypeset on your typesetter??
Not that I know of. But Charlie Brown's office did use it.
Brown, the CEO of AT&T, did not like wearing reading glasses
when he made a speech, so his speechwriters produced the
text in large type. Once they were into document preparation
they began to use our machine for other things. When I
discovered that confidential minutes of AT&T board meetings
were in our file system, I told them the facts of life
about computer security, especially at the center of the
UUCP universe, and persuaded the executive suite to get
its own machine.
Doug
the one at WH was directly connected to a vax 11/780, no paper tape either.
so that now finally explains why /dev/cat was write only, it was substituted
for a paper tape reader. it was always a curiosity that you could write
to it, yet never read it (i.e. get a status). a "cat /dev/cat" would
get you a "cat: cannot open /dev/cat" while a "cat /some/file > /dev/cat"
would succeed, but act like you used /dev/null instead
(as /some/file was not valid phototypeseter input)
> From: Doug McIlroy
>
> > The wikipedia description
> > <http://en.wikipedia.org/wiki/CAT_(phototypesetter)>
> > seems pretty accurate although I have never seen the beast myself.
>
> I can confirm the wikipedia description. At Bell Labs, however, we
> did not use paper tape input. As soon as the machine arrived, Joe
> Ossanna bypassed the tape reader so the C/A/T could be driven
> directly from the PDP-11. The manufacturer was astonished.
>
> The only operational difficulty we had was with the separate
> developer. If you didn't hand feed the end of the paper perfectly
> straight into that machine, the paper would tear. Joe Condon
> fixed that by arranging for the canister to sit on rollers so
> it could give when the paper pulled sideways.
>
> The first technical paper that came off the C/A/T drew a query
> from the journal editor, who'd never seen a phototypeset
> manuscript before: had it been published elsewhere?
>
> Doug
>
Look at United States Patent 4074285
http://patentimages.storage.googleapis.com/pdfs/US4074285.pdf
Figure 1 is identical to the machine I ran at Whippany Bell Labs
in the early to mid 80s. It was about 4 1/2 feet tall
Figure 4 is the font wheel (seen as 16 in Fig 1) there were 4 distinct
sectors, each with a different font. One with Times Roman, one with
Times Roman Bold, one with Times Roman Italic and the last was the
symbol fonts (math, greek chars, left hand (\lh right hand \(rh etc. and
this one was made specifically for the Labs as it had a Bell Logo \(bs on it)
The paper was a roll of photo paper, glossy on the text side, rough on
the reverse, it was thick. It would end up going into the cassette
(20 in Fig 1) and would need to be developed. Not shown in the patent
figures was the developing and drying apparatus. At the end of
a job the exposed paper was in the cassette you'd remove
it from the typesetter and put into a device with rollers that would pull
it out and run it thru developer and fixer liquid chemicals. Exiting
that it would go into a dryer drum.
After it was completly dry, as it was still a continuous roll, you
would need to cut all the pages apart by hand (that is why there was
the cut mark macro (.CM) is -ms so you could tell where to cut)
As it came from a roll, no pages ever layed completely flat.
The checmical baths were nasty smelling and it gummed up the rollers.
You'd needed to regularly take the developer roller and gear guts into
the janitor's closet and scrub it with a toothbrush in the slop sink
under running water.
By the second half of the 80s it was replaced by QMS PostScript
laser printers.
> From: "Jacob Goense" <dugo(a)xs4all.nl>
> All, I'm looking for images of the cat device as mentioned several
> times in the 7th edition manual, see e.g. TROFF(1)and CAT(4).
>
> From what I gathered during my digs is that it should look like a
> GSI 8400, but that didn't help. Anyone here who can help me find out
> what these machines looked like? A picture would be the best, but
> information on what to look for in images of unnamed typesetters will
> do as well.
>
> /Jacob
>
>
All, I'm looking for images of the cat device as mentioned several
times in the 7th edition manual, see e.g. TROFF(1)and CAT(4).
>From what I gathered during my digs is that it should look like a
GSI 8400, but that didn't help. Anyone here who can help me find out
what these machines looked like? A picture would be the best, but
information on what to look for in images of unnamed typesetters will
do as well.
/Jacob
Hi all.
This may be of some interest. From a friend at Utah:
> Date: Sat, 30 Nov 2013 16:06:25 -0700 (MST)
> Subject: [it-professionals] computer history: Arpanet IMPs resurrected
>
> The simh list about simulators for early computers recently carried
> traffic about an effort to reconstruct and resurrect the Arpanet
> Interface Message Processors (IMPs), which were the network boxes that
> connected hosts on the early Arpanet, which later became the Internet.
>
> There is a draft of a paper about the work here:
>
> The ARPANET IMP Program: Retrospective and Resurrection
> http://walden-family.com/bbn/imp-code.pdf
>
> Utah was one of the original gang-of-five hosts on the Arpanet, and we
> received IMP number 4. Utah is mentioned twice in the article, and
> also appears in the map in Figure 3 on page 14.
>
> One amusing remark in the article (bottom of page 7) has to do with
> the fail-safe design of the IMPs:
>
> In addition ``reliability code'' was developed to allow a
> Pluribus IMP to keep functioning as a packet switch in the
> face of various bits of its hardware failing, such as a
> processor or memory [Katsuki78, Walden11 pp. 534-538]. This
> was so successful there was no simple off switch for the
> machine; a program had to be run to shut parts of the machine
> down faster than the machine could ``fix itself'' and keep
> running.
>
> As happened with early Unix releases, machine-readable code for the
> IMPs was lost, but fortunately, some old listings that turned up
> recently allowed its laborious reconstruction, verification, assembly,
> and simulation.
Arnold
Clem Cole <clemc(a)ccc.com> wrote:
>If the original BBN code had
>been left alone, since most people did not have the issues Berkeley did,
>they would never have bothered with sendmail.cf.
Now I might be badly wrong, but nonetheless this strikes me as
badly revisionist history.
The motivation for sendmail.cf was the collision of multiple
namespaces (Arpanet, Bitnet, Usenet, etc.), each implemented
in varying nonstandard ways by different mail clients and servers,
resulting in messes like "IJQ3SRA%UCLAMVS.BITNET%SU-LINDY(a)SU-CSLI.ARPA",
as one of many, many examples, as observed in the famous
"The Hideous Name", Rob Pike & P.J. Weinberger, 1985
http://pdos.csail.mit.edu/~rsc/pike85hideous.pdf
The thing is, although sendmail.cf was/is itself hideous to understand
and therefore make maintenance changes to (although I have), it is
quite capable of actually handling the above kinds of messes, and
being extended to handle new messes as they turn up.
In short, it got the job done, despite its weaknesses.
I may be wrong, but it was my strong impression that, back in the
day, this could not be said of anyone else's code, BBN or otherwise.
Doug Merritt
I am reading the delivermail (later known as postbox and then sendmail)
code from 4.0BSD and from sccs history from June 1980.
Its arpa-mailer(8) manual says it just spools the letter and actual
delivery will be performed by the ARPANET mailer daemon and refers to
mailer(ARPA) manual. The arpa.c code says "is stuck away in the
outgoing arpanet mail queue for delivery by the true arpanet mailer."
Where is this true arpanet mailer? I am guessing it periodically looks
in /usr/spool/netmail/ and delivers the messages using FTP and RFC458.
Where is this mailer(ARPA) manual?
Where is the ftp server code used for the incoming mail? (Example
code mail-dm.c is provided for the ftp server to "handle the MAIL <user>
command over the command connection.")
Also where is the uucp-mailer(8) manpage referenced in delivermail(8)?
Jeremy C. Reed
echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \
tr '#-~' '\-.-{'
On Mon, Nov 25, 2013 at 04:55:58PM -0600, Jeremy C. Reed wrote:
> Kashtan's VMS performance comparison paper and Joy's followup from early
> 1980 both refered to the VM/UNIX as Version 2.1 of the Berkeley system;
> this was the "Third" distribution; by April the kernel was known as 3.1.
>
> 2.4BSD was mentioned in the kermit source's Makefile. But maybe a
> mistake.
I stand well corrected!
Thanks,
Warren
Just saw this on the ClassicCMP list. Wonder if anyone could read it out... or if it's actually something that's already out there.
--Dave
Begin forwarded message:
> From: Chuck Guzis <cclist(a)sydex.com>
> Subject: 4.3BSD source tape offered on FreeBSD
> Date: November 25, 2013 at 2:29:19 PM EST
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>
> Reply-To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org>
>
> http://forums.freebsd.org/showthread.php?t=43346
(For reference ... I am writing a detailed history of Berkeley Unix ...)
Does anyone have a copy of and the story about the Univ. of Toronto
license used for their tape distributions around 1977?
In an interview in Linux Magazine, Volume 1, Number 6, in November
1999, Joy said he just took a license from the University of Toronto
and modified it a little bit and started using that for his BSD.
It was a one-page license.
I have a copy of an early one page license (from AUUGN newsletter V01.3,
Feb/Mar 1979) which was used for the Pascal and Ex release, but it says
"(first) Berkeley Software Tape" on it which seems odd to number the
real first distribution. Also the copy of the license I have is for $60,
but the first distribution tapes were $50; these amounts are both
documented in various places for 2BSD and 1BSD respectively. Since maybe
the one page license says "(first)" and "$60", maybe there is a
different earlier license?
I also tried Googling for some of the terminology but didn't find any
hits.
So does anyone have a copy of the license for the Univ. of Toronto tape
distribution from the mid 1970's?
On that note, can anyone tell me about the story of the Toronto Unix
distributions? I understand in late 1978, the Univ. of Toronto Computing
Services group and some other Toronto-area installations were providing
their own Unix distributions for standardization of their commonly used
commands and were forming the "Toronto Distribution Centre" (mentioned
by Gregory Hill, see AUUGN V01.2, Dec-78 / Jan-79). But within a few
years, the UTCS was using BSD.
Jeremy C. Reed
echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \
tr '#-~' '\-.-{'
Hi, all!
Sorry for slightly off-topic question, but do anybody have a copy of
original circa 1969 RS232C standard? I need it to resolve conflict with me
and my customer regarding if RS-232C REQUIRES the use of DE-25M connector
or just
RECOMMENDS it? It seems that there is a lot of interpretations of this
standard, but
no original document anywhere :(
I know it might cost $$$, but I will pay all needed fees.
All the best,
S.
> Hi all,
> I am hoping this list is still alive, since I'd like to find out a bit
more info about this backplane.
> It's part of an 11/23 system (based on CPU) that is made by Netcom. It
had
> standard DEC
> cards in it DLV11, M8021 bootstrap board etc. Apparently the system ran
a
> few years back
> before it was put in storage.
I have a few Netcom boxes at home. I'll try to remember to look
at what models when I go home.
> I aquired it, in the hopes of bringing it
> back to life and getting
> it to successfully display a login: prompt.
That would depend on the OS more than the hardware. :-)
> I have read through the archives, esp. a post from Michael Sokolov back
in
> 98, where he describes
> the different types of QBus'es. Q/Q, Q/CD etc.
> It looks like the backplane that I have (according to some documents
written at SLAC in late 70's)
> is a serpentine or sinusoidal.
> A diagram on the cardcage describes as follows:
> A B C D
> ------------>
> <-----------
> ------------->
> <------------
> There is also a blurb about slot 2/CD being wired differently. Two slots
on the diagram are pre-printed for RL controllers.
There were backplanes like that for the two card RL controller.
> My CPU card is a later rev. D so it can do 22bit addressing. I'd like if
possible to run 22bits, since this would allow
> me at a later time to put in a 11/73 cpu that would run 2.11.
I may be wrong (but I am sure someone here will correct me) but if the
backplane is designed for the two card RL controller I think it will be 18
bit and not capable of 22 bit.
> How would I go about checking if the backplane is wired for 22bits or
not.
> I seem to remeber the standard qbuses had the W1-W4 pins (?)
> that you could wirewrap to change from 18to22, but this backplane has
nothing like that.
I would guess you could look at it and see how many bits are wired thru.
And, if you have a clear view of the wirewrap side you should be able to
see if it has two A-B-C-D slots in the middle. Difference in wirewrap
pattern will be obvious. :-)
> Also, in the present configuration, with an 11/23 and 128Kw, could I run
v6 or v7 (assuming I can get some form of supported disk storage)? At
present
> I only have a floppy controller and a bunch of 8" Shugart 801 drives..
What floppy controller? Dec didn't use the standard Shugart 8" inteface
for RX01/RX02 disks. If it is like the Terak which also used 801's you
are going to need to find drivers for what OS you decide to use. Good
luck with that.
> thanks in advance for any replies.
You might try asking on alt.sys.pdp11 as there are a lot much more
knowlegable people than I active over there.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill(a)cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Ian,
Thanks for the response and the pointer to the web page. Looks like I can run 2.9 on the machine - I just have to find myself some RL's 8-)
Did some digging around on QBus, and think i found enough info, that coupled with some contiuity tests should allow me to figure out exactly how the backplane is laid out.
regards
alex
----- Original Message -----
>From: "Ian King" <IanK(a)LivingComputerMuseum.org>
>To: "azd30" <azd30(a)telus.net>, pups(a)minnie.tuhs.org
>Sent: Wednesday, October 23, 2013 11:47:19 AM
>Subject: RE: Netcom HV-1148 QBus Backplane
>You would probably be better served on the ClassicCmp mailing list. This list is primarily about software, specifically Unix on the PDP-11.
>I'd have to dig to answer your question, and there's probably someone on ClassicCmp who can do so off the top of his/her head. (And I already have my hands full: I'm at work looking at bringing up an IFS to talk to a Xerox Alto.)
>Take a look at the PUPS webpage for more information on installing e.g., V6 or V7 on various machines. My recollection is that these versions have requirements in hardware, such as the switch register, that may make them unsuitable for a Qbus machine - but the PUPS page >has a section that can answer definitively. -- Ian
Hi all,
I am hoping this list is still alive, since I'd like to find out a bit more info about this backplane.
It's part of an 11/23 system (based on CPU) that is made by Netcom. It had standard DEC
cards in it DLV11, M8021 bootstrap board etc. Apparently the system ran a few years back
before it was put in storage. I aquired it, in the hopes of bringing it back to life and getting
it to successfully display a login: prompt.
I have read through the archives, esp. a post from Michael Sokolov back in 98, where he describes
the different types of QBus'es. Q/Q, Q/CD etc.
It looks like the backplane that I have (according to some documents written at SLAC in late 70's)
is a serpentine or sinusoidal.
A diagram on the cardcage describes as follows:
A B C D
------------>
<-----------
------------->
<------------
There is also a blurb about slot 2/CD being wired differently. Two slots on the diagram are pre-printed for RL controllers.
My CPU card is a later rev. D so it can do 22bit addressing. I'd like if possible to run 22bits, since this would allow
me at a later time to put in a 11/73 cpu that would run 2.11.
How would I go about checking if the backplane is wired for 22bits or not. I seem to remeber the standard qbuses had the W1-W4 pins (?)
that you could wirewrap to change from 18to22, but this backplane has nothing like that.
Also, in the present configuration, with an 11/23 and 128Kw, could I run v6 or v7 (assuming I can get some form of supported disk storage)? At present
I only have a floppy controller and a bunch of 8" Shugart 801 drives..
thanks in advance for any replies.
--
alex
How to to extract a ".tap" file? What tools?
I found http://man.cat-v.org/unix-1st/1/tap manual but I haven't found
corresponding tool (even in tuhs source code archive).
The file I am trying to extract is
http://bitsavers.trailing-edge.com/bits/BSD/BSD4.1_bootable.tap.gz (12
MB). I can view some of the plain text in it.
I tried historical ar (which I have used for some other 1970's images),
restore, and tar. file(1) says it is a "Maple help database".
Jeremy C. Reed
echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \
tr '#-~' '\-.-{'
PRESS RELEASE - PLEASE COPY AND SHARE!
APPLE 1
FRIDAY, Sept. the 13th
at the "Museo dell'Informatica Funzionante" Computer Museum
Via Carnevale 17, 96010 Palazzolo Acreide (SR) - ITALY
http://museo.freaknet.org/en/presentazione-progetto-apple-1/
The APPLE 1 marked the start of the era of "personal computing",
a computer that people could keep at home on their desks, a
pioneer vision at that time, that opened the way for the future
of human-machine interfaces. Born from the genius of Steve
Wozniak, it transformed Apple into today ‘s success, thanks also
to the entrepreneurial audacity of Steve Jobs.
At that time only about 200 pieces were produced; today only
about 50 of them survived, of which only a dozen are fully
working. The APPLE 1 was an open project since its birth: he
schematics and instructions were already circulating among fans
well before the creation of Apple as a company. From this early
computer, Steve Wozniak created the legendary APPLE 2, a
colossal success that transformed him and Steve Jobs into
billionaires.
We started this adventure almost two years ago at the "Museo
dell'Informatica Funzionante" Computer Museum: to rebuild from
scratch, starting from a completely blank electronic card, a
working APPLE 1, using tools and components dated exactly or
before its creation: 1976.
A year and a half was spent searching for integrated circuits,
connectors, electronic components of various types, bought new
or second-hand, found in various parts of the world, but all
identical to the originals, with the right features and from the
same historical period. The project, managed by a local team,
involved fans and professionals from all the world.
So we present today our creation, made entirely in
Sicily, Palazzolo Acreide, Italy: a specimen of APPLE Computer
1, fully functional, rebuilt with attention to every detail and
using only original components at the best of our possibility!
With this release we intend to invite everyone to the event of
his first start, in person or remotely via our live streaming.
Friday, September 13, 2013:
19:00 - Presentation of the APPLE 1 project and the computer
19.30 - Booting up the rebuilt APPLE 1 Computer, and operational
demo
20:00 - Aperitif
Remote presence:
Via live chat on IRC: https://irc.dyne.org, channel #museo
Live video streaming: http://bambuser.com/channel/musif
On Twitter: follow @FreaknetMuseum
All people in Palazzolo Acreide can also have a guided tour of
our exibithion "Apple, il genio di Steve Wozniak", dedicated to
the genius of Steve Wozniak and his creations, with working
Apple computers and memorabilia from 1978 to 1999.
For more information, press kits and interviews please write to
museo(a)freaknet.org
Spam detection software, running on the system "www.oztivo.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.
Content preview: ÀÎÁõÆäÀÌÁö½Ã¾È1 [...]
Content analysis details: (6.0 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT
[211.32.24.57 listed in bb.barracudacentral.org]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
1.1 URI_HEX URI: URI hostname has long hexadecimal sequence
0.0 WEIRD_PORT URI: Uses non-standard port number for HTTP
0.4 HTML_IMAGE_RATIO_02 BODY: HTML has a low ratio of text to image area
0.0 HTML_MESSAGE BODY: HTML included in message
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
0.7 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
0.0 T_REMOTE_IMAGE Message contains an external image
The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam. If you wish to view
it, it may be safer to save it to a file and open it with an editor.
> CB/UNIX was developed to address deficiencies inherent in Research Unix,
> notably the lack of interprocess communication and file locking
CB/UNIX was one of several versions in various divisions of Bell Labs
to implement IPC facilities beyond pipes and signals. Top management
in a division would declare that they wanted to use Unix, but needed
some particular IPC mechanism: semaphores, events, message passing, etc.--
and needed it right away. I always believed that these demands stiffer
as they percolated up through channels to the point that no alternative
mechanism would do. We in research would have preferred to seek a
general solution that would suffice to serve the various demands.
Besides, anything that we produced but didn't use ourselves would
automatically be suspect. We were very wary of featuritis.
Roughly speaking, each demand led to a different local flavor of
Unix, each (I like to think) reflecting the particular variant of
IPC with which one of its system designers worked in graduate
school. Somewhere between the wariness of research Unix, where
an ethos of generality ruled, and Linux, which offers a dozen ways
to do anything, there must lie a happy medium--a medium that I
believe would be much closer to Unix than Linux. That, alas, has
not proved to be the way of open source.
All, I'll be moving house sometime in the next few months, so I thought
I would start scanning in the paper documents that I've got. I've just
completed the scan of the CB/UNIX manuals that Larry Cipriani sent in
a while back. You can find them here:
http://www.tuhs.org/Archive/PDP-11/Distributions/other/CB_Unix/
and here is the blurb I put in there.
Cheers,
Warren
CB/UNIX was a variant of the UNIX operating system internal to Bell
Labs. It was developed at the Columbus, Ohio branch and was little-known
outside the company. CB/UNIX was developed to address deficiencies
inherent in Research Unix, notably the lack of interprocess communication
and file locking, considered essential for a database management
system. Several Bell System operation support system products were
based on CB/UNIX such as Switching Control Center System. The primary
innovations were power-fail restart, line disciplines, terminal types,
and IPC features similar to System V's messages and shared memory.
So far we have a scanned copy of the CB/UNIX manuals which were donated
to TUHS by Larry Cipriani. Copies of the binaries and source code would
be much appreciated. There were two volumes of manuals. The first volume
held cbunix_intro, cbunix_man1 and cbunix_man1L. The second volume held
the remaining sections. The 'L' in the scans indicates local sections of
the manuals, i.e. those elements created and maintaned at Columbus.
In an e-mail from Larry, he asked a retired CB/UNIX developer about the
major features that were added to UNIX by CB/UNIX. Was it primarily messages,
semaphores, named pipes, shared memory? The developer replied:
Other things that immediately come to mind that we added first
in Columbus Unix were power-fail restart (myself and Jim McGuire did the
initial work) and line-disciplines and terminal types (Bill Snider did
the initial work). Hal Person (or Pierson?) also rewrote the original
check disk command into something that was useful by someone other than
researchers. Bill Snider and Hal Pierson were really instrumental in
taking UNIX from research and applying it to SCCS (Switching Control
Center System). I worked with them when I first hired on. When we
first used UNIX on an 11/20 with core memory it was written in assembler
(1974). It quickly went through "B" and we started using the C version
in early 1975 as I recall. We also did some enhancements to the scheduling
algorithms in UNIX to make them more "real-time" capable.
On Jul 24, 2013, at 7:00 PM, tuhs-request(a)minnie.tuhs.org wrote:
> What parts are missing from the archive mentioned by Poul-Henning Kamp?
>
> http://www3.alcatel-lucent.com/bstj/
>
> It has 1922 to 1983. I was assuming that missing issues like 1942 issues 2
> through 4 were not ever published.
I've got Vol 68, No. 8 October 1984, the second 'Unix System' edition of the BLTJ.
Additional articles on all things Unix:
Evolution of the UNIX Time-sharing system
Program Design in the UNIX System Environment
The Blit: A Multiplexed Graphics Terminal
Debugging C programs with the Blit
UNIX Operation System Security
File Security and the UNIX System Crypt Command
The Evolution of C - Past and Future
Data Abstration in C by B. Stroustrup - The first C++ mention that I know of in the Journal
Multiprocessor UNIX Systems
A UNIX System Implementation for System/370
UNIX Operating System Porting Experiences
The evolution of UNIX System Performance
Cheap Dynamic Instruction Counting
Theory and Practice in the Construction of a Working Sort Routine
The Fair Share Scheduler
The Virtual Protocol Machine
A Network of Computers Running the UNIX System
A Stream Input-Output System (D M Richie) - SYS V streams implementation description
David
Ken Thompson has famously said that the only thing he'd do
differently if he were to do Unix afresh would be to spell
"create" with a final e. The BSTJ cameo (or product placement?)
reveals another example: he'd spell Unix as an ordinary proper
name. Once the marketers had glommed onto "UNIX" as a trademark,
we were regularly badgered when when we tried to naturalize
the name. References to "Unix" in internal documents were
scrubbed to "UNIX" for external consumption. I'd like to think
that by exhibiting "Unix" in an image Netravali et al
intentionally cocked a snook at corporate orthodoxy.
Incidentally, the online BSTJ is complete. A new publication,
the AT&T Technical Journal took its place after 1983, with
a new format and quite different content. The replacement
publication was a house organ, not a research journal.
Doug
All, I got this interesting e-mail from Poul-Henning a few days ago.
Warren
----- Forwarded message from Poul-Henning Kamp <phk(a)phk.freebsd.dk> -----
Date: Sat, 20 Jul 2013 13:27:27 +0000
From: Poul-Henning Kamp <phk(a)phk.freebsd.dk>
To: wkt(a)tuhs.org
Subject: A cameo by UNIX in BSTJ
Some months ago I faced a flight from Denmark to NZ and back again,
so I bought a Kobo eBook reader and reformatted the entire BSTJ to fit
the screen.
That gave me about 100k "pages" to read, plenty for my NZ-flights
and a large number of otherwise wasted moments since then. Highly
recommeded.
Recently I came over what I belive is the first mention of UNIX in BSTJ.
We all know about the v57i6, July-August 1978 "UNIX Time-Sharing System"
issue, but it transpires that UNIX made a cameo two years earlier
in an article about compression-schemes for TeleFax:
www3.alcatel-lucent.com/bstj/vol55-1976/articles/bstj55-10-1539.pdf
Enjoy,
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk(a)FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
----- End forwarded message -----
