I apologise if this is too far from the main topic, but I wanted to check
an urban legend.
There is a story - as I have heard it told - that PDPs established their
place (and popularity) in the marketplace by pointedly *not* advertising
themselves as "computers", but instead as "programmed data processors".
This was because - so the story goes - that everyone in corporations of the
time simply *knew* that "computers" came only from IBM, lived in big
datacentres, had million-dollar price-tags, and required extensive project
management to purchase; whereas nobody cared enough about a thing called a
"programmed data processor" to bother bikeshedding the
few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an
inevitable death. Thus, they flitted under the purchasing radar, and sold
like hotcakes.
I wonder: does this story have substance, please?
Aside from anything else: I draw parallels to the adoption of Linux by Wall
St, and the subsequent adoption of virtualisation / AWS by business - now
reflected in companies explaining to ISO27001 auditors that "well, we don't
actually possess any physical servers..."
- alec
--
http://dropsafe.crypticide.com/aboutalecm
I think that steep educational discounts and equipment grants from Digital to major collages also had a major impact,as did the existence of DECUS that made a lot of software readily available.
Best regards,
David Ritchie
Charles Babbage KH FRS was born on this day in 1791; pretty much the
father of the computer, a model of his "difference engine" built to the
standards of the day worked, complete with its printer. What is not so
well known about him was that he dabbled in cryptography, and broke the
Vigenère cipher; unfortunately for him it was classified as a military
secret, so one Friedrich Kasiski got the credit instead.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Somewhat tangentially related to the other thread...
So, back in the days when I was using Consensys SVR4.2, I found a bug in
tar. It goes like this:
If there is a symbolic link in the tree that you are taring, the first
one works fine. If a second symbolic link has a shorter destination name
than the first, the extra characters from the first symbolic link
destination are appended to the end of the second. So for example:
a -> abcdef
b -> zyx
Tar will actually tar these symbolic links as:
a -> abcdef
b -> zyxdef
Being that I happen to have found, on the Internet, the sources to AT&T
SVR4.2, and some other System V variants, I went and investigated.
The relevant piece from AT&T SVR4.2 tar.c (broken):
Jan 25Â 1993 ./ATT/ATT-SYSVr4/cmd/tar/tar.c
       case S_IFLNK:
            <SNIP>
               i = readlink(shortname, filetmp, NAMSIZ - 1);
               if (i < 0) {
                       vperror(0, "can't read symbolic link %s",
longname);
                       return;
               }
From USL-4.2 (apparently fixed):
Jan 22Â 1994 ./USL/usl-4.2-source/src/i386/cmd/tar/tar.c
       case S_IFLNK:
            <SNIP>
               i = readlink(shortname, filetmp, NAMSIZ - 1);
               if (i < 0) {
                       vperror(0, ":462:Cannot read symbolic link %s",
longname);
                       return;
               }
               else
                       filetmp[i] = '\0';  /* since readlink does not
supply a '\0' */
From Solaris 2.5:
       case S_IFLNK:
            <SNIP>
               i = readlink(shortname, filetmp, NAMSIZ - 1);
               if (i < 0) {
                       vperror(0, gettext(
                       "can't read symbolic link %s"), longname);
                       if (aclp != NULL)
                               free(aclp);
                       return;
               } else {
                       filetmp[i] = 0;
               }
BSD 4.4:
       case S_IFLNK:
            <SNIP>
               i = readlink(shortname, dblock.dbuf.linkname, NAMSIZ - 1);
               if (i < 0) {
                       fprintf(stderr,
                           "tar: can't read symbolic link %s: %s\n",
                           longname, strerror(errno));
                       return;
               }
               dblock.dbuf.linkname[i] = '\0';
Anyone know when/why/how tar diverged between the two branches? Note the
readlink directly into dblock.dbuf, while the SVR4 variants use a temp
string and then sprintf it in later.
From: http://www.catb.org/esr/faqs/usl-bugs.txt
17. tar(1) fails to restore adjacent symbolic links properly
Arthur Krewatt <...!rutgers!mcdhup!kilowatt!krewat> reports:
SVR4 tar has another strange bug. Seems if when restoring files, you
restore one file that is a link, say "a ->/a/b/c/d/e" and there is another
link just after it called "b ->/a/b/c" tar will restore it as "b ->/a/b/c/d/e"
This just seems to be a lack of the NULL at the end of the string, like
someone did a memmov or memcpy(dest,src,strlen(src)); where it should be
strlen(src)+1 to include the NULL.
Esix cannot reproduce this under 4.0.4 or 4.0.4.1, they think it's fixed.
Hello Team TUHS:
I am having a problem with my PDP-11 SVR1 running under a recent SIMH build. My problem occurs on both MAC OS X and FreeBSD.
First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1. The system behaves beautifully as FSCK reports clean. Eight users can login with no problem.
Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below.
Third, when using the tape driver instead of /dev/null i get the same results.
Next, here is the issue:
cd /
find . -print | cpio -ocvB > /dev/null
It runs for a short while and then shitz a core:
I am using /dev/null to take the tape driver out of the equation.
Here is the backtrace for cpio:
$c
__strout(053522,043,0,053012)
__doprnt(046652,0177606,053012)
_fprintf(053012,046652,053522)
~main(02,0177636)
Now, interestingly, I run into a similar issue when using tar:
cd /usr
tar -cvf /dev/null .
Again, this will run for a while, then drops a core. Here is the backtrace for tar:
$c
__strout(043123,02,0,045506)
__doprnt(043123,0167472,045506)
_fprintf(045506,043123,0170600)
~putfile(0170600,0170641)
~putfile(0171654,0171704)
~putfile(0172730,0172745)
~putfile(0174004,0174016)
~putfile(0175060,0175066)
~putfile(0176134,0176136)
~putfile(0177672,0177672)
~dorep(0177632)
~main(04,0177630)
This really bugging me since my SVR1 is otherwise working flawlessly. I was able to remake the entire system and custom kernels that boot with no problem.
Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world!
I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11?
Thank you for any help.
Would you expect tar or cpio to dump core if you attempted to copy large filesystems (or the entire system) on a PDP-11?
Note: All of my testing has been in single user mode.
Truly,
Bill Corcoran
> From: Dave Horsfall
> Colossus, arguably the world's first electronic computer
Well, it all depends on your definition of "computer"... :-)
I myself prefer to reserve that term for things that are programmable,
and Turing-complete. (YMMV... :-)
So I call things like Colossus and ABC "digital electronic calculating
devices" (or something similar).
None of which is to take anything away from the incredible job done by Flowers
and his cohorts. It was an amazing device, and had a major effect on history.
Noel
Tommy Flowers MBE was born on this day in 1905; an electrical and
mechanical engineer, he designed Colossus, arguably the world's first
electronic computer, which was used to break the German "Lorenz"
high-level cipher (not Enigma, as some think).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Before we had to phase out our FTP server, I kept on it several
versions of UNIX clones and related OS that were mostly not on TUHS.
This post is to remember some of these systems. Many of these were
open sourced or widely available at some time and were related to UNIX
one way or another. I may not have the latest versions or all the
versions, but at least I do keep something.
The following ones have been open sourced at some point in time (I
believe):
ChorusOS
Coherent
EXOS
L4
Lunix
MaRTE-OS
Mach
OpenBLT
OpenSolaris
Sprite (I also own the original distribution CD)
Trix
UniFlex
agnix
amoeba
bkunix
bsd386
hurd
iunix
jaluna-c5
lsx-unix
mini-unix
minix
omu
opensolaris
starunix
thix
from tliquest.net/local/unix: uzi and various other bits
tme
tropix
tunix
unix-v8
unix-wega
uzi
xhomer
xinu
xv6
yoctix
Plus several archaic CDs with early versions of Linux,
Open/Free/NetBSD, (Walnut Creek, InfoMagic, etc. CD/ROMs)
and even the Beowulf/Extreme Linux CDs (plus I must keep around the
mirror we hosted for a long time of the Beowulf site). The hobbyist CDs
for OpenSolaris 8 (and I believe 9) with sources. Oh, and
MOSIX/OPENMOSIX.
In addition, I have many other sources whose Copyright status I'm not
aware of, but which are interesting for archival purposes.
Regarding QNX, yes, it was open sourced (at least for hobbyist use, I
have to check the license) for several distributions. I ported some
bioinformatics software and kept for some time a distribution
repository, and I'm pretty certain I must have the sources as well as
the virtual machines. I'll try to verify the licenses to see if it can
be redistributed, although I doubt they can. Oh, and I also own the
mentioned famous 3.5" diskette. I think I digitized it long ago. Would
have to check.
Off the Net, it has been possible, one time or another, to recover
executables and, sometime, even sources, of many systems. Archive.org
has -I believe- a copy of a once famous repo of abandonware with
binaries of SCO, System V, AIX, etc...
I know that AIX, ATT systemV vI, II, III and IV, Solaris V6, Tru64,
OSF-1, Dynix, Ultrix 11, BSDI, Ultrix-32 etc... have been out there at
some time or another in source code format, and binaries of IRIX, Lisa,
QNX, A/UX, xenix...
Some years ago, I had more free time and could test many systems on
emulators, and built images and accompanying scripts ready ti run. I
also made some tools to be able to transfer data in and out of old
unix versions (so I could edit the software off the virtual machine
while back-porting a screen editor to V6, v5, etc... with only vt100
support).
Not UNIX-related, I also keep copies of many other ancient operating
systems and software and hardware emulators.
Well, as I said at the beginning, everything that I had, I should still
keep while the hard disks continue spinning. If there is any
interest in adding any of these to TUHS, I can try to find a way to
send it all.
If I find time to browse through everything, I would like to upload all
the source code to GitHub (at least anything that's redistributable).
If I find the time...
But, Warren, if you are interested in anything, let me know and I'll
find a way to give you access.
j
--
Scientific Computing Service
Solving all your computer needs for Scientific
Research.
http://bioportal.cnb.csic.es
I blundered today into the GECOS field in /etc/passwd:
https://en.wikipedia.org/wiki/Gecos_field
"Some early Unix systems at Bell Labs used GECOS machines for print
spooling and various other services,[3] so this field was added to
carry information on a user's GECOS identity."
I had forgotten about this field and I don't recall it being
previously described as related to GECOS (I likely didn't take note at
the time I first encountered it).
Aside from the influence of Multics and other things on UNIX design
are there other tangible[1] manifestations of non-UNIX operating
system things like the GECOS field that were carried forward intact in
later UNIX implementations?
[1] things can be pointed at, rather than design ideas
