Micnet would seem to fall within my interest scope of Unix networking 1975-1985. I’ve seen it mentioned before, but I don’t have a clear picture of what it was.
There is some sysadmin material on bitsavers about it, but no info on how it worked on the inside or how it relates to other early networking.
At first glance it seems to be conceptually related to Berknet.
Does anybody here know the backstory to Micnet and/or how it worked?
Paul
Hello UNIX veterans.
So I stumbled online upon a copy of the book "SCO Xenix System V Operating
System User's Guide", from 1988, advertised as having 395 pages, and the
asked for price was 2.50 EUROs. I bought it, expecting --well, I don't know
exactly what I was expecting, something quaint and interesting, I suppose.
I've received the book, and it is not a treasure trobe, to say the least. I
am in fact surprised at how sparse was UNIX System V of this age, almost
spartan.
The chapter titles are:
1. Introduction
2. vi: A Text Editor
3. ed
4. mail
5. Communicating with Other Sites
6. bc: A Calculator
7. The Shell
8. The C-Shell
9. Using the Visual Shell
And that's it. The communications part only deals the Micnet (a serial-port
based local networking scheme), and UUCP. No mention at all of the words
"Internet" or "TCP/IP", no even in the Index.
Granted, this Xenix version is derived from System V Release 2, and I think
it was for the Intel 286 (not yet ported to the i386), but hey it's 1988
already and the Internet is supposed to be thriving on UNIX in the Pacific
Coast, or so the lore says. I see now that it probably was only in the
Berkely family that the Internet was going on...
In truth, I fail to see what was the appeal of such a system, for mere
users, when in the same PC you could run rich DOS-based applications like
WordPerfect, Lotus 1-2-3, Ventura Publisher and all the PC software from
those years.
I mean, mail without Internet is pretty useless, althouhg I understand it
could be useful for inter-company communications. And yes, it had vi and the
Bourne Shell. But still, it feels very very limited, this Xenix version,
from a user's point of view.
I'm probably spoiled from Linux having repositories full of packaged free
software, where the user just has to worry about "which is the best of":
email program, text editor, browser, image manipulation program, video
player, etc. I understand this now pretty well, how spoiled are we these
days.
--
Josh Good
> When you're the phone company, calls are free
Not so. But the culture prioritized phone use in a way
that's been completely forgotten. High execs would
answer their own phones when they were at their
desks. "Your call is very important to us. Please wait
for the first available representative" would have been
anathema.
One of my few managerial decrees in the Unix lab was
to give a year's notice that "research" would stop
forwarding Usenet traffic, not because of phones, but
because uucp was becoming a burden on our computer.
Doug
Connectivity evolved rapidly in the early 1980s. In 1980 I served on the
board of CSNet, which connected have-not CS departments (including Bell
Labs) via dialup and X.25 links onto the periphery of the magic circle
of Arpanet.
By 1982 it was not extraordinary that I could via international email arrange
all aspects of a trip to visit lively universities of the AUUG.
OK. So, I've been trying to decide (for the last time, I swear) whether
to use tabs or spaces in my code... I did a quick pulse-check on the
state of argument and it appears to be alive and well in 2021. My
question for y'all is, was there a preference in the very early days or
not? I saw an article talking about the 20 year feud, but that's not my
recollection. In 1994, nobody agreed on this, but I'm sure it predates
my entree into the field. I'm thinking the history of entab and detab
are somehow related, but I've been wrong on these sorts of thoughts
before. What say you?
Will
Amazing coincidences. A week prior I was researching Topper Toys
looking for their old factory ("largest toy factory in the world")
As there was litte on it's location and it lead me to find out
in 1961 it took over the old Singer Factory in Elizabeth, NJ.
So looking up the Singer factory led me to "Elizabeth,
New Jersey, Then and Now" by Robert J. Baptista
https://ia801304.us.archive.org/11/items/ElizabethNewJerseyThenAndNowSecond…
Which had no information on Topper, but had had this paragraph in it's Singer
section on page 28 --
Boys earned money "rushing the growler" at lunchtime at the Singer plant.
German workers lowered their covered beer pails, called growlers, on ropes
to the boys waiting below. They earned a nickel by filling them with beer
at Grampp's saloon on Trumbull St. One of these boys was Thomas Dunn who
later became a long term Mayor. In the early 1920s Frederick Grampp went
into the hardware business at the corner of Elizabeth Ave. and Reid St.
When I read it I thought funny, as I know the name Fred Grampp. But beleived
just a coincidenental same name. After reading the biography post, I went back
to the book as it turns out that Fred Grampp is your Fred Grampps's
grandfather. You can find more his family and the hardware store and
Grampp himself on pages 163-164, and 212.
-Brian
Wow this is nothing short of GREAT!
I always wanted to tackle this but it was out of my reach as I barely got
anything from this lineage to build to anything.
Most excellent!
-----Original Message-----
From: MOCHIDA Shuji
To: tuhs(a)minnie.tuhs.org
Sent: 3/6/21 10:42 AM
Subject: [TUHS] 4.4BSD sparc, pmax binary recently compiled
I compiled 4.4BSD to get pmax and sparc binary, from CSRG Archive
CD-ROM #4
source code.
http://www.netside.co.jp/~mochid/comp/bsd44-build/
pmax:
- Works on GXemul DECstaion(PMAX) emulation.
- I used binutils 2.6 and gcc 2.7.2.3 taken from Gnu ftp site,
as 4.4BSD src does not contain pmax support part in as, ld,
gcc and gdb.
- Lack of GDB. I got rid of compile errors of gdb 4.16, but that
does not work yet.
- gcc included can not deal c++ static constructor. So,
contrib/groff
can not be compiled. Instead, it uses old/{nroff,troff,eqn,tbl..}.
sparc:
- Works on sun4c. I use on SPARCstation 2, real hardware.
TME sun4c emulation can boot to single user, but it locks up in
middle of /etc/rc.
CSRG Archive CD-ROM #4's source code (just after Lite2 release) seems
have differences from CSRG's binary distributions before (2 times),
e.g. mount systemcall is not compatible.
I used NetBSD 1.0/sparc, NetBSD 1.1/pmax for 1st (slightly) cross
compiling. NetBSD 1.0/sparc boots and works well on TME emulator.
SunOS 4.1.4, Solaris7 works too, but this 4.4BSD binary doesn't..
-mochid
As I remember it, the Facilities folks were so upset about
someone painting stuff on Their Water Tower that a complaint
went to Vic Vyssotsky, then Executive Director of Division
112 (one step up from Sandy Fraser, who was Director of 1127).
The story was that Vic and/or Sandy told them that there were
60 people in the research centre and no way to tell who did it.
Word was then quietly passed to certain people--Vic and Sandy
in fact knew exactly who--that things were getting out of hand,
please lay off the Peter-face pranking for a while.
I tried to start a rumour that Vic did the painting, but it
never took off. I hope Vic at least heard it. He'd have
enjoyed the rumour, surely laughed at the prank while knowing
he'd have to calm things down, and 20 years earlier might well
have been involved in something like that.
It was Vic who, on learning I was a cyclist, urged me to try
cycling on the newly-constructed but not yet open segment of
interstate highway that ran behind the Labs. He apparently
had done so and found it lots of fun. Alas, I never did.
Norman Wilson
Toronto ON
BBN’s TCP implementation contained something akin to the hosts file, called hostmap there:
https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/doc
I have not looked at the code for a while, but if I remember correctly the BBN kernel code also read in this file (pre-processed into a binary form) to build its internal routing table.
I do not recall having seen an equivalent file with UoI's NCP Unix in any of the surviving docs or sources - but that does not exclude a library having existed to do lookups in a local copy the SRI-NIC host file. In fact there is some evidence for that in the 2.9 BSD source.
The only surviving copy of the 4.1a (network) source code that I know is in the back-port of this code to 2.8/2.9 BSD. This code includes #ifdef’ed code for accessing the SRI-NIC online host table via NCP:
https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/local
This source also contains tools to convert the SRI-NIC data into - inter alia - a hosts file:
https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/man/man8/htable.8https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/man/man8/gettable…
It would seem that the modern host.txt on Unix evolved late ’81 (BBN code) to early ’82 (4.1a BSD). Possibly NCP Unix has prior work.
Paul
Hi,
I'm not sure where this message best fits; TUHS, COFF, or Internet
History, so please forgive me if this list is not the best location.
I'm discussing the hosts file with someone and was wondering if there's
any historical documentation around it's format and what should and
should not be entered in the file.
I've read the current man page on Gentoo Linux, but suspect that it's
far from authoritative. I'm hoping that someone can point me to
something more authoritative to the hosts file's format, guidelines
around entering data, and how it's supposed to function.
A couple of sticking points in the other discussion revolve around how
many entries a host is supposed to have in the hosts file and any
ramifications for having a host appear as an alias on multiple lines /
entries. To whit, how correct / incorrect is the following:
192.0.2.1 host.example.net host
127.0.0.1 localhost host.example.net host
--
Grant. . . .
unix || die
In the Seventh Edition manual, a joke was added to
the entry for kill(1). It appears in every following
Research manual, but seems to have been discarded
by all modern descendants.
I guess the prejudice against humour in the manual
is extreme these days.
Norman Wilson
Toronto ON
In all that's been written about the Research Unix players,
Fred Grampp has gotten far less coverage than he deserves.
I hope to rectify that with this post, most of which was
written soon after his death.
Doug
During Fred's long career at Bell Laboratories, his coworkers
were delighted to work with him, primarily because of his
innovative and often surprising ways of attacking problems.
Fred's unique approach was by no means limited to work-related
matters. Fred arranged an annual canoe-camping trip on the
Delaware River replete with nearly professional grade fireworks.
He also arranged a number of trips to New York City (referred
to as culture nights) which included, among other things,
trips to the planetarium and visits to various tea rooms.
To his friends at Bell Labs, Fred Grampp was a true original. He
knew the urban community of small, scrabbling business
as well as the pampered life of industrial research in the
country's greatest industrial research lab. And he brought
the best of each to his approach to work.
In his father's hardware store, Fred learned on the front line
what "customer-oriented" meant--a far cry from the hypothetical
nonsense on the subject put forth by flacks in a modern PR
department, or by CEO Bob Allen thinking big thoughts on the
golf course.
Fred ran the computing facilities for the Computer Science
Research Center. He had his finger on the pulse of the machinery
at all hours of day and night. He and his colleague Ed Sitar
rose early to pat the hardware and assure that everything was
in order just as had been done at the hardware store. The rest
of us, who kept more nerdish hours, could count on everything
running.
Packed with equipment, the machine room depended on
air conditioning. Fred saw this as a threat to dependable
service. As a backup, he had big galvanized barn fans installed
in several windows--incongruous, but utterly practical. And
they saw actual use on at least one occasion.
Fred cooked up ingenious software to sniff the computers'
health and sound alarms in his office and even by his bed when
something was amiss. When a user found something wrong and
popped into Fred's office to report the trouble, more often
than not he'd find Fred already working on it.
With his street smarts, Fred was ahead of the game when
computer intrusion began to become a problem in the 1970s.
He was a real white-hat marshall, who could read the the bad
guys' minds and head them off at the pass. With Bob Morris,
Fred wrote a paper to alert system administrators to the kinds
of lapse of vigilance that leave them open to attack; the paper
is still read as a classic. Other sage advice was put forth
by Fred in collaboration with G. R. Emlin, who would become an
important adjunct member of the lab, as several TUHS posts attest.
Quietly he developed a suite of programs that probed a
computer's defenses--fortunately before the bad guys really
got geared up to do the same. That work led to the creation
of a whole department that used Fred's methods to assess and
repair the security of thousands of computers around Bell Labs.
Fred's avocations of flying and lock-picking lent spice to
life in the Labs. He was a central figure of the "computer
science airforce" that organized forays to see fall colors,
or to witness an eclipse. He joined Ken Thompson, who also
flew in the department air force, on a trip to Russia to fly
a MIG-29. Ken tells the story at cs.bell-labs.com/ken/mig.html.
Fred's passion for opera was communicated to many. It was
he who put the Met schedule on line for us colleagues long
before the Met discovered the World Wide Web. He'd press new
recordings on us to whet our appetites. He'd recount, or take
us to, rehearsals and backstage visits, and furnish us with
librettos. When CDs appeared on the scene, Fred undertook to
build a systematic collection of opera recordings, which grew
to over two hundred works. They regularly played quietly in the
background of his office. To Fred the opera was an essential
part of life, not just an expensive night on the town.
Fred's down-to-earth approach lightened life at Bell Labs. When
workmen were boarding up windows to protect them from some major
construction--and incidentally to prevent us from enjoying the
spectacle of ironworkers outside. Fred posted a little sign
in his window to the effect that if the plywood happened to
get left off, a case of Bud might appear on the sill. For the
next year, we had a close-up view of the action.
Fred, a graduate of Stevens Institute, began his career in
the computer center, under the leadership of George Baldwin,
perhaps the most affable and civic-minded mathematician I have
ever met. At the end of one trying day, George wandered into
Fred's office, leaned back in the visitor chair, and said,
"I sure could use a cold one about now." Fred opened his window
and retrieved a Bud that was cooling on the sill.
Fred lived his whole life in Elizabeth, New Jersey. At one
point he decided that for exercise he could get to the Labs by
train to Scotch Plains and bike from there up to Bell Labs--no
mean feat, for the labs sat atop the second range of the
Watchung Mountains, two steep climbs away from Scotch Plains.
He invested in a folding bike for the purpose. Some days
into the new routine a conductor called him out for bringing
a bicycle onto the train. Fred had looked forward to this
moment. He reached into his pocket, pulled out a timetable
and pointed to the fine print: bicycles were prohibited with
the exception of folding bikes.
Originally dated October 25, 2000. Lightly edited and three
paragraphs added February 22, 2021.
Rob Pike:
I don't believe the water tower was a one-person job.
====
I agree. Even if GR Emlin helped, I bet two live people
were involved in painting.
I'm quite sure more than that participated in making the
stencil.
Norman Wilson
Toronto ON
PS: I have never been on a water tower.
On Mar 11, 2021, at 10:08 AM, Warner Losh <imp(a)bsdimp.com> wrote:
>
> On Thu, Mar 11, 2021 at 10:40 AM Bakul Shah <bakul(a)iitbombay.org> wrote:
>> From https://www.freebsd.org/cgi/man.cgi?hosts(5)
>> For each host a single line should be present with the following information:
>> Internet address
>> official host name
>> aliases
>> HISTORY
>> The hosts file format appeared in 4.2BSD.
>
> While this is true wrt the history of FreeBSD/Unix, I'm almost positive that BSD didn't invent it. I'm pretty sure it was picked up from the existing host file that was published by sri-nic.arpa before DNS.
A different and more verbose format. See RFCs 810 & 952. Possibly because it had to serve more purposes?
> Warner
>
>>> On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote:
>>> Hi,
>>>
>>> I'm not sure where this message best fits; TUHS, COFF, or Internet History, so please forgive me if this list is not the best location.
>>>
>>> I'm discussing the hosts file with someone and was wondering if there's any historical documentation around it's format and what should and should not be entered in the file.
>>>
>>> I've read the current man page on Gentoo Linux, but suspect that it's far from authoritative. I'm hoping that someone can point me to something more authoritative to the hosts file's format, guidelines around entering data, and how it's supposed to function.
>>>
>>> A couple of sticking points in the other discussion revolve around how many entries a host is supposed to have in the hosts file and any ramifications for having a host appear as an alias on multiple lines / entries. To whit, how correct / incorrect is the following:
>>>
>>> 192.0.2.1 host.example.net host
>>> 127.0.0.1 localhost host.example.net host
>>>
>>>
>>>
>>> --
>>> Grant. . . .
>>> unix || die
>> _______________________________________________
>> COFF mailing list
>> COFF(a)minnie.tuhs.org
>> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
In 1972, while in high school, I went to an Intel seminar on the 8008.
There I met a Bell Labs scientist who gave me a sample 8008 and invited
me for a visit at some NJ Bell Labs facility. That group had a
timesharing system of some kind, but it was not Unix. I was also given a
Bell Labs speech synthesis kit after meeting one of the speech
scientists who happened to be in on the same Saturday. I have searched
my attic but can't find further details. Would any of you alumni recall
what this other timesharing system might have been?
Dan
Hello everyone,
I'm Wojciech Adam Koszek and I'm a new member here. After a short stint with Red Hat 6.0 and Slackware Linux around 2000-2001 (I think it was Slackware 7.0 or 7.1) my journey with UNIX started with FreeBSD 4.5. I fell in love with BSD and through Warner Losh, Robert Watson, and folks from a Polish UNIX scene, I became hooked. I ended up working with FreeBSD for the following 15 years or so.
Anyway: the volume of the UNIX literature back then in Poland was scarce, yet through a small bookstore and a friendly salesman I got myself a "UNIX Network Programming Volume 1" at a huge discount, and read it back-to-back.
Looking back, his books had a huge impact on my life (I had all his books, and read everything line by line, with a slight exception of TCP/IP illustrated vol 2, which I used as a reference), and while Stevens's website sheds some light on what he did, I often wonder what is the story behind how his books came to be. It doesn't help he appeared a very private person--never have I seen a photo of him anywhere.
What was the reception of his books in the US?
Did you know him? Do you know any more details about what he did after 1990?
Thanks and take care,
Wojciech Adam Koszek
Following my success in getting 6th Edition UNIX running on a KDF11-B,
with support for the MSCP disk controller, I was looking for ways to get
as new a tool chain as possible onto it, with full source code (as I'd
been using the tool chain from UNSW, for which the source is missing).
Well, it turns out that there's an even newer one in PWB, and there are
complete source and binary PWB distributions in the TUHS archive!
I now have PWB/UNIX 1.0 running, and completely rebuilt from its own
sources, on one of my physical /23+ boxes (and, of course, in simh).
It's connected to my main (NetBSD) system using UUCP over a serial line.
Oh, and it runs the University Ingres RDBMS. :)
The write-up (and download) is at https://www.hamartun.priv.no/pwb.html
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea in computer science. --Alan Kay
Here is a link to the 1897 bill of the Indiana State Legislature
that legislated a new value for $\pi$:
https://journals.iupui.edu/index.php/ias/article/view/4753/4589
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- 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/ -
-------------------------------------------------------------------------------
> The reason to use tab was file size for one
This is urban legend. The percentage of 512-byte blocks that
tabs would save was never significant.
(I agree that tabs and--especially--newlines can significantly
compress fixed-field formats from punched-card tradition, but
on the tiny Unix systems where tab conventions were
established, big tabular files were very rare.)
Tabs were a convenience for typists. Of course the tty driver
could have replaced them with spaces, but that would have
foreclosed important usage such as tab-separated fields and
run-time-adjustable tab stops tab-separated fields.
(I have run into latter-day trouble with selecting a space-substituted tab
from a screen, only to discover that I was copying or searching for spaces
instead of the tab.. That's not an intrinsic problem, though. Editors like sam
handle it without fuss.)
Doug
I compiled 4.4BSD to get pmax and sparc binary, from CSRG Archive CD-ROM #4
source code.
http://www.netside.co.jp/~mochid/comp/bsd44-build/
pmax:
- Works on GXemul DECstaion(PMAX) emulation.
- I used binutils 2.6 and gcc 2.7.2.3 taken from Gnu ftp site,
as 4.4BSD src does not contain pmax support part in as, ld,
gcc and gdb.
- Lack of GDB. I got rid of compile errors of gdb 4.16, but that
does not work yet.
- gcc included can not deal c++ static constructor. So, contrib/groff
can not be compiled. Instead, it uses old/{nroff,troff,eqn,tbl..}.
sparc:
- Works on sun4c. I use on SPARCstation 2, real hardware.
TME sun4c emulation can boot to single user, but it locks up in
middle of /etc/rc.
CSRG Archive CD-ROM #4's source code (just after Lite2 release) seems
have differences from CSRG's binary distributions before (2 times),
e.g. mount systemcall is not compatible.
I used NetBSD 1.0/sparc, NetBSD 1.1/pmax for 1st (slightly) cross
compiling. NetBSD 1.0/sparc boots and works well on TME emulator.
SunOS 4.1.4, Solaris7 works too, but this 4.4BSD binary doesn't..
-mochid
> From: John Floren
> Can anyone on the list point me to either an existing archive where
> these exist
The canonical repository for historic documentation online is BitSavers.
It has an almost-complete set of DEC stuff (both manuals and prints. QBUS
devices are at:
http://www.bitsavers.org/pdf/dec/qbus/
QBUS CPU's will be in the relevant model directory, e.g.:
http://www.bitsavers.org/pdf/dec/pdp11/1123/
and disk drives are in:
http://www.bitsavers.org/pdf/dec/disc/
I haven't checked your list, but I suspect most of them are there; I think the
ADV11-A prints are missing, though. You can either send the originals to Al
Kossow, or scan them for him; but check with him first, to make sure he doen't
already have them, just hasn't got around to posting them yet.
There's another site which indexes DEC online documentation:
https://manx-docs.org/
There are a very few things which aren't in Bitsavers, and can be found there.
> KFD11-A cpu
I assume that's a typo for 'KDF11-A'?
Noel
I've been hauling around a pile of DEC Field Maintenance Print Sets
for PDP-11 components for over a decade now, intending to see if
they're worth having scanned or if there are digital versions out
there already. Can anyone on the list point me to either an existing
archive where these exist, or an archivist who would be interested in
scanning them? They're full of exploded diagrams, schematics, and
assembly listings.
Here's the list of what I have:
Field Maintenance Print Set (17" wide, 11" high):
RLV11 disk controller
RL01-AK disk drive
ADV-11A (??)
Field Maintenance Print Set (14" wide, 8.5" high):
RL01 disk drive
DLV11-J serial line controller
RLV11 disk controller
KFD11-A cpu
KEF11-A floating point processor
PDP11/23
PDP11/03-L
Thanks,
John Floren
I could chip in with my own strong opinions about code formatting,
but I think others have already posted plenty of such boring off-topic
fluff.
A straight answer to Will's original question might be interesting,
though:
The oldest extant UNIX code samples I know are those the TUHS archive,
in Distributions/Research/Dennis_v3/nsys.tar.gz; they're a very old
kernel source tree. There are plenty of tabs there.
This matches my memories of the V7-era source code, and of what I saw
people like ken and dmr and rob and bwk and pjw typing in the not-
so-early days of the 1980s when I worked with them.
Tabs were generally eight spaces apart. In code, nobody worried about
the effects on long lines, because the coding style was spare and
didn't run to many deeply-nested constructs, so lines didn't get that
long. (Maybe it was considered a feature rather than a bug that
deep nesting and deep indentation looked messy, because it wasn't
usually a good idea anyway.)
I can't speak to original motivations, but I suspect my own reasons
for using tabs aren't too different:
-- It's quicker and faster to type than multiple spaces
-- When not at the start of the line, tabs more often preserve
alignment when earlier part of the line are edited
-- Back when terminals were connected at speeds like 110 or 300 bps
(I am old enough to have experienced that, especially when working
from home), letting the system send a tab and the local terminal
expand it was a lot faster, especially when reading code (more likely
to have lots of indentation than prose). Not every device supported
tabs, but enough did that it made a real difference.
UNIX didn't originate any of this. I used tabs when writing in FORTRAN
and ALGOL/SIMULA and MACRO-10 on the TOPS-10 system I used before I
encountered UNIX. So did all the other hackers I knew in the terminal
room where we all hung out.
I don't know the history of entab/detab. Neither appears to have
been around in the Research systems; they're not in V7 and they're
not in V10. V7 does.
As an aside, the V10 manual has a single manual page for col, [23456],
mc, fold, and expand. It's a wonderful example of how gracefully
Doug assembled collections of related small programs onto a single
page to keep the manual size down. Also of his gift for concise
prose: the first sentence is
These programs rearrange files for appearance's sake.
which is a spot-on but non-stodgy summary. I wish I could write
half as well as Doug can.
And as an almost-joke, it's a wonder those programs haven't all been
made into options to cat in modern systems.
Norman Wilson
Toronto ON
For sure, I've seen at least two interesting changes:
- market forces have pushed fast iteration and fast prototyping into the
mainstream in the form of Silicon valley "fail fast" culture and the
"agile" culture. This, over the disastrous "waterfall" style, has led to a
momentous improvement in overall productivity improvements.
- As coders get pulled away from the machine and performance is less and
less in coders hands, engineers aren't sucked into (premature) optimization
as much.
Tyler
On Sat, Jan 30, 2021 at 6:10 AM M Douglas McIlroy <
m.douglas.mcilroy(a)dartmouth.edu> wrote:
> Have you spotted an evolutionary trend toward better, more productive
> programmers? Or has programmer productivity risen across the board due to
> better tools? Arguably what's happened is that principle has been
> self-obsoleting, for we have cut back on the demand for unskilled (i.e.
> less capable) programmers. A broad moral principle may be in play:
> programmers should work to put themselves out of business, i.e. it is wrong
> to be doing the same kind of work (or working in the same way) tomorrowas
> yesterday.
>
> Doug
>
>
> On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams <coppero1237(a)gmail.com> wrote:
>
>> Looking at the 1978 list, the last one really stands out:
>>
>> "Use tools in preference to unskilled help to lighten a programming task"
>> -- The concept of unskilled help for a programming task...doesn't really
>> exist in 2020. The only special case is doing unskilled labor yourself.
>> What unskilled tasks did people used to do back in the day?
>>
>> Tyler
>>
>>
>> On Tue, Jan 26, 2021 at 4:07 AM M Douglas McIlroy <
>> m.douglas.mcilroy(a)dartmouth.edu> wrote:
>>
>>> It might be interesting to compare your final list with the two lists in
>>> the 1978 special issue of the BSTJ--one in the Foreword, the other in the
>>> revised version of the Ritchi/Thompson article from the CACM. How have
>>> perceptions or values changed over time?
>>>
>>> Doug
>>>
>>>
>>> On Mon, Jan 25, 2021 at 7:32 AM Steve Nickolas <usotsuki(a)buric.co>
>>> wrote:
>>>
>>>> On Mon, 25 Jan 2021, Tyler Adams wrote:
>>>>
>>>> > I'm writing about my 5 favorite unix design principles on my blog this
>>>> > week, and it got me wondering what others' favorite unix design
>>>> principles
>>>> > are? For reference, mine are:
>>>> >
>>>> > - Rule of Separation (from TAOUP <
>>>> http://catb.org/~esr/writings/taoup/html/>
>>>> > )
>>>> > - Let the Machine Do the Dirty Work (from Elements of Programming
>>>> Style)
>>>> > - Rule of Silence (from TAOUP <
>>>> http://catb.org/~esr/writings/taoup/html/>)
>>>> > - Data Dominates (Rob Pike #5)
>>>> > - The SPOT (Single Point of Truth) Rule (from TAOUP
>>>> > <http://catb.org/~esr/writings/taoup/html/>)
>>>> >
>>>> > Tyler
>>>> >
>>>>
>>>> 1. Pipes
>>>> 2. Text as the preferred format for input and output
>>>> 3. 'Most everything as a file
>>>> 4. The idea of simple tools that are optimized for a single task
>>>> 5. A powerful scripting language built into the system that, combined
>>>> with
>>>> 1-4, makes writing new tools heaps easier.
>>>>
>>>> -uso.
>>>>
>>>
> - separation of code and data using read-only and read/write file systems
I'll bite. How do you install code in a read-only file system? And
where does a.out go?
My guess is that /bin is in a file system of its own. Executables from
/letc and /lib are probably there too. On the other hand, I guess
users' personal code is still read/write.
I agree that such an arrangement is prudent. I don't see a way,
though, to update bin without disrupting most running programs.
Doug