[TUHS] long lived programs

[TUHS] long lived programs

[Norman Wilson]

Steve Johnson:

  But in this case, part of the requirement was to pass some standard
  simulation tests (in FORTRAN, of course).  He was complaining that
  these programs had bugs and didn't give the right answer.

====

This reminds me of an episode during my time at Bell Labs.

The System V folks wanted to make pipes that were streams;
our experience in Research showed that that was useful.  We'd
done it just by making pipe(2) create a stream.  This caused
some subtle differences in semantics (pipes became full-duplex;
writing to a pipe put a delimiter in the stream, so that a
corresponding read on the other end would stop at the delimiter;
write(pipefd, "", 0) therefore generated something that would
make read(pipeotherfd, buf, len) return 0).  We'd been running
all our systems that way for a while, and had uncovered no
serious problems.

But the System V folks were very nervous about it anyway, and
wrote a planning document in which they proposed to create a
new, different system call to make stream pipes.  pipe(2) would
make an old-fashioned pipe; spipe(2) (or whatever it was called,
I forget the name) had to be called to get a stream.  The document
didn't really explain the justification for this.  To us in
Research it just sounded crazy.

Someone else was going to attend a meeting with the developers,
but at the last minute he had a conflict, so he drafted me to
go.  Although I can be pretty blunt in writing, I try not to be
so much so in person when dealing with people I don't know; so
rather than asking how they could be so crazy as to add a new
kind of pipe, I asked why they really thought it necessary.

It took a little probing, but the answer turned out to be that
their management insisted that everything pass an official
verification suite to prove compliance with the System V,
Consider It Standard; and said verification suite didn't just
check that the first file descriptor returned by pipe(2) could
be read and the second written, it insisted that the first could
not be written and the second not read.  Full-duplex pipes didn't
meet the standard, it was claimed.

I asked what exactly is the standard?  The SVID, I was told.

What does the SVID really say, I wondered?  We got a copy and
looked up pipe(2).  According to the official standard, the
first file descriptor must be readable and the second writeable,
but there was no statement that it couldn't work the other way too.
Full-duplex pipes did in fact meet the standard; it was the
verification suite that, in an excess of zeal, didn't conform.

The developers were absolutely delighted with this.  They too
thought it was stupid to have two different kinds of pipes,
particularly given our experience that full-duplex delimited
pipes didn't break anything.  They were very happy to have
Research not just yell at them for doing things differently
from us, but help them figure out how to justify doing things
right.

I don't know just how they took this further with management,
but as it came out in SVr4, pipe(2) returned a full-duplex
stream.  This is still true even unto Solaris 10, where I just
tested it.

I made friends that day.  That developer group kept in touch
with me as they did further work on pipes, the terminal driver,
pseudo-ttys, and other things.  I didn't agree with everything
they did, but we were able to discuss it all cordially.

Sometimes the verification program just needs to be fixed.
And sometimes the developers that seem set on doing the wrong
thing really want help in subverting whatever is forcing that
on them, because they really do know what the right thing is.

Norman Wilson
Toronto ON

[TUHS] long lived programs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

On Thu, Apr 5, 2018 at 5:03 PM, Norman Wilson <norman at oclsc.org> wrote:

> Sometimes the verification program just needs to be fixed.
> And sometimes the developers that seem set on doing the wrong
> thing really want help in subverting whatever is forcing that
> on them, because they really do know what the right thing is.
>
​I like to refer to this as acting intelligently.  And think a little about
why an earlier implementation had a particular artifact. It is amazing how
people can blindly follow ​

​something because it has been that way.   Not that you change things
willy-nilly (aka Henry's Spencer's wonderful line:  "4.2 BSD is just like
Unix ..... only different."

Two favorite examples are <CR><LF> and case folding.

Both are historical artifacts which made sense in an older age, but
hardware outgrew then.   Steve discussed the <CR><LF> stuff a few week ago,
so I'll not repeat; but it was always amazing to me that it got codified
forever, in the 'text' file idea in things like the C standard -- how
completely silly and what a waste of resources and engineering effort over
the years.

Case folding I find funnier however. Back in the days of 5 and 6 bit codes,
particularly when file names were stored in things like rad50 it made
perfect sense.   The basic character code did not handle upper and lower
well, and many keyboards were only one case anyway.   But by the time of
the 8 bit byte, CP/M and it's child DOS, blindly follow along.  Instead of
thinking why it was done and since we have a new file system format and
thinking -- hmmm maybe we don't need to have the same limitation.

Clem​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180405/f9c96115/attachment.html>

[TUHS] long lived programs

[Bakul Shah]

May be case itself is such a historical artifact?  AFAIK all non-roman scripts are without case distinction. 

> On Apr 5, 2018, at 2:23 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> Two favorite examples are <CR><LF> and case folding.
> 
> Both are historical artifacts which made sense in an older age, but hardware outgrew then.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180405/3dccdbce/attachment.html>

[TUHS] long lived programs

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

On 4/5/2018 5:23 PM, Clem Cole wrote:
> Case folding I find funnier however. Back in the days of 5 and 6 bit 
> codes, particularly when file names were stored in things like rad50 
> it made perfect sense.   The basic character code did not handle upper 
> and lower well, and many keyboards were only one case anyway.   But by 
> the time of the 8 bit byte, CP/M and it's child DOS, blindly follow 
> along.  Instead of thinking why it was done and since we have a new 
> file system format and thinking -- hmmm maybe we don't need to have 
> the same limitation.
>

I come from the world of SIXBIT on TOPS-10. One of my first tasks for 
LIRICS/BOCES was to write a replacement for MIC, while still in High 
School. The TTY I used did only upper case. So all the comments in that 
source code were in upper case.

When it came to real ASCII, and keyboard input, you could never assume 
that the TTY was going to give you lower case by default (or upper, for 
that matter). What to do? Be case-insensitive in everything you do.

While I understand the simplicity of the code that had to deal with 
filenames in UNIX (no flipping bits), I don't understand why a file 
README.TXT is different than readme.txt in UNIX.

Now, I love UNIX - I wouldn't have it any other way, but I often wonder 
what the design goal was. As for a "limitation" for case-sensitive file 
names, it's more like a feature to me.

art k.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180405/09f883d8/attachment.html>

[TUHS] long lived programs

[Paul Winalski]

On 4/5/18, Clem Cole <clemc at ccc.com> wrote:
>
> Case folding I find funnier however. Back in the days of 5 and 6 bit codes,
> particularly when file names were stored in things like rad50 it made
> perfect sense.   The basic character code did not handle upper and lower
> well, and many keyboards were only one case anyway.   But by the time of
> the 8 bit byte, CP/M and it's child DOS, blindly follow along.  Instead of
> thinking why it was done and since we have a new file system format and
> thinking -- hmmm maybe we don't need to have the same limitation.
>
Maybe CP/M and DOS stored file names internally in rad50 or some other
compressed form, to save space?  The first PCs didn't have much memory
(64K), and floppies didn't have much capacity.  It was a throwback to
the "every bit counts" design and programming days of the 60s/early
70s.

-Paul W.

[TUHS] long lived programs

[Arthur Krewat]

On 4/5/2018 7:23 PM, Paul Winalski wrote:
> Maybe CP/M and DOS stored file names internally in rad50 or some other
> compressed form, to save space?
Definitely not DOS, and I doubt CP/M did either.

art k.

[TUHS] long lived programs

[Toby Thain]

On 2018-04-05 7:33 PM, Arthur Krewat wrote:
> On 4/5/2018 7:23 PM, Paul Winalski wrote:
>> Maybe CP/M and DOS stored file names internally in rad50 or some other
>> compressed form, to save space?
> Definitely not DOS, and I doubt CP/M did either.

Right. CP/M used (restricted) ASCII for directory entries.

--T

> 
> art k.
> 
> 

[TUHS] long lived programs

[Random832]

On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote:
> May be case itself is such a historical artifact?  AFAIK all non-roman 
> scripts are without case distinction.

Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction in Japanese is similar to case in some ways (including limited computer systems using only one)

Full list of scripts in unicode that have case distinctions (based on analyzing character names): Adlam, Armenian, Cherokee, Coptic, Cyrillic, Deseret, Georgian, Glagolitic, Greek, Latin, Old Hungarian, Osage, and Warang Citi.

[TUHS] long lived programs

[Warner Losh]

On Thu, Apr 5, 2018, 8:04 PM Random832 <random832 at fastmail.com> wrote:

> On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote:
> > May be case itself is such a historical artifact?  AFAIK all non-roman
> > scripts are without case distinction.
>
> Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction
> in Japanese is similar to case in some ways (including limited computer
> systems using only one)
>

Really? Those must be quite old as everything I've seen has both. But the
difference between kata and kana is much larger than upper and lower case.
It is rare to convert one to another as they are used to write different
things. Only to look things up in a dictionary would you convert, and then
you'd also be converting kanji to...

In Roman languages, very little is changed with all caps, though a few
things become ambiguous depending on the language...

In Japanese, it could turn some foreign loan word into a native word with a
totally different meaning...

Warner

> Full list of scripts in unicode that have case distinctions (based on
> analyzing character names): Adlam, Armenian, Cherokee, Coptic, Cyrillic,
> Deseret, Georgian, Glagolitic, Greek, Latin, Old Hungarian, Osage, and
> Warang Citi.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180406/59f22529/attachment.html>

[TUHS] long lived programs

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3682 bytes --]

Just to make life more interesting, in the early days anything other
than letters and numbers were often different for different
manufacturers.  I seem to recall Bell Labs buying a custom "print
chain" in order to get enough special characters to handle printing
programming languages (Doug, this was almost before my time -- do you
remember the details?).   I remember there was a device that could
print the contents of a punched card on the punched card itself.  It
had a number of quirks, including that it only printed 40 (or was it
50) columns of the 80-column card, and had virtually no special
symbols.  We quickly became adept at looking at the garbled
subsection of the card and intuiting which card it really was...

I became all to familiar with that card printer during one summer
job.  I was working for Stan Brown, who had written a symbolic
algebra system in assembler.   It was a real tour-de-force, and
contained several thousand punched cards.  When I started my summer
job, Stan made a copy of all the cards for me, so we each had a
copy.   Shortly after I arrived, the comp center announced a
brand-new feature -- permanent disc storage!  (actually, I think it
was a drum...).   Stan and I were excited about the possibility that
we could edit the single copy of the program and not have to keep our
copies in sync, so we loaded the cards into the file.  There was a
crude editor that would allow you to make one pass through the file in
order, deleting lines or adding card images after certain line
numbers.   You needed a printout of the file that told you the line
numbers, but the printout was much easier to handle than the punched
cards...

A couple of days after the program was safely on the drum, Stan threw
out his card deck, assuming that I had the backup copy.  At about the
same time, I threw out my card deck, assuming that Stan had a copy. 
We discovered this the hard way when I tried to do a fairly
substantial edit of the file on disc.  It turned out that the editor
only worked correctly when you wrote the edited file into a new
file.  If you didn't specify a new file, it attepted to do the edit
on top of the file as it edited, creating a jumble of fragments of the
original file -- typically 3-10 lines.   By the time we realized
this, the file was good and trashed, and we had no backup.   But we
did have a listing...

So I punched out the mangled file onto cards, and fed them through the
card printer, and spent the weekend comparing line by line -- in many
cases, I could simply move the punched cards into the proper order,
but I did plenty of card punching as well.  Amazingly, I managed to
get it working again, and Stan and I kept updated punched cards
throughout the summer...

Steve

----- Original Message -----
From: "Random832" <random832@fastmail.com>
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Thu, 05 Apr 2018 22:03:40 -0400
Subject:Re: [TUHS] long lived programs

 On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote:
 > May be case itself is such a historical artifact? AFAIK all
non-roman 
 > scripts are without case distinction.

 Greek and Cyrillic both have cases. And the Hiragana/Katakana
distinction in Japanese is similar to case in some ways (including
limited computer systems using only one)

 Full list of scripts in unicode that have case distinctions (based on
analyzing character names): Adlam, Armenian, Cherokee, Coptic,
Cyrillic, Deseret, Georgian, Glagolitic, Greek, Latin, Old Hungarian,
Osage, and Warang Citi.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180405/bdf5527b/attachment.html>

[TUHS] long lived programs

[Jon Steinhart]

> Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction
> in Japanese is similar to case in some ways (including limited computer
> systems using only one)

Hiragana and Katakana are not cases.  Hirigana is used for words of
Japanese origin; Katakana is used for "foreign" words.

[TUHS] long lived programs

[Dave Horsfall]

On Thu, 5 Apr 2018, Norman Wilson wrote:

> [...] write(pipefd, "", 0) therefore generated something that would make 
> read(pipeotherfd, buf, len) return 0).

Just like what I suggested at UniNSW in the 70s, and got ignored :-)  It 
might even be in AUUGN too, along with my suggestion that stty() be 
applied to devices other than terminals...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] long lived programs

[Steve Nickolas]

On Fri, 6 Apr 2018, Warner Losh wrote:

> On Thu, Apr 5, 2018, 8:04 PM Random832 <random832 at fastmail.com> wrote:
>
>> On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote:
>>> May be case itself is such a historical artifact?  AFAIK all non-roman
>>> scripts are without case distinction.
>>
>> Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction
>> in Japanese is similar to case in some ways (including limited computer
>> systems using only one)
>>
>
> Really? Those must be quite old as everything I've seen has both. But the
> difference between kata and kana is much larger than upper and lower case.
> It is rare to convert one to another as they are used to write different
> things. Only to look things up in a dictionary would you convert, and then
> you'd also be converting kanji to...
>
> In Roman languages, very little is changed with all caps, though a few
> things become ambiguous depending on the language...
>
> In Japanese, it could turn some foreign loan word into a native word with a
> totally different meaning...
>
> Warner

Some computers in the early 80s, like the Apple ][ J-Plus, only do 
katakana.

-uso.

[TUHS] long lived programs

[Jon Steinhart]

> In Japanese, it could turn some foreign loan word into a native word with a
> totally different meaning...

Not the way that it works.  Hiragana and katakana have exactly the same number
of characters with exactly the same pronunciation and the same meaning.  The
difference is more akin to using italics to indicate foreign words.

[TUHS] long lived programs

[Bakul Shah]

On Thu, 05 Apr 2018 22:03:40 -0400 Random832 <random832 at fastmail.com> wrote:
Random832 writes:
> On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote:
> > May be case itself is such a historical artifact?  AFAIK all non-roman 
> > scripts are without case distinction.
> 
> Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction in 
> Japanese is similar to case in some ways (including limited computer systems 
> using only one)
> 
> Full list of scripts in unicode that have case distinctions (based on analyzi
> ng character names): Adlam, Armenian, Cherokee, Coptic, Cyrillic, Deseret, Ge
> orgian, Glagolitic, Greek, Latin, Old Hungarian, Osage, and Warang Citi.

Thanks. I was being lazy. I understand old Latin, Greek &
Cyrillic scripts used only one case?  And that modern Georgian
does not distinguish cases though its alphabet has *several*
variants.  Osage is very new and Cherokee script was designed
in early 1800s (influenced by the europeans). So it seems
a) case sensitive scripts are mainly alphabets and 
b) lower case letters must've been a later addition. 
[I can see why case was never added to abugida languages like
 the Indian languages -- they already have a large number of
 glyphs and complex shapes to remember!]

Getting back to programming languages, I am not sure case
distinction really helps. Many of the earlier languages such
as Algol, PL/I, APL, Pascal, Fortran, Cobol, Lisp didn't have
it and I don't think it was solely due to an attempt to pack
more chars in a word. Capitalization can improve legibility in
written languages but the meaning of a word often doesn't
change in spite of case change. In modern PLs the meaning can
be entirely different, and even the category (DO vs do) and I
am not sure that increases legibility. Not to mention the
camelCaseHorror. Much prefer hyphenated-words (and use of
space before the negative sign when needed).

[TUHS] long lived programs

[Tony Finch]

Norman Wilson <norman at oclsc.org> wrote:
>
> We'd done it just by making pipe(2) create a stream.  This caused some
> subtle differences in semantics (pipes became full-duplex; writing to a
> pipe put a delimiter in the stream, so that a corresponding read on the
> other end would stop at the delimiter;

Was it 4.4BSD which implemented pipe() using socketpair() under the
covers? Full-duples like streams, but without the delimiters.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
a fair voting system for all elections

[TUHS] long lived programs

[Peter Jeremy]

On 2018-Apr-05 22:57:49 -0700, Bakul Shah <bakul at bitblocks.com> wrote:
>Getting back to programming languages, I am not sure case
>distinction really helps. Many of the earlier languages such
>as Algol, PL/I, APL, Pascal, Fortran, Cobol, Lisp didn't have
>it and I don't think it was solely due to an attempt to pack
>more chars in a word.

Early APL implementations do have cases - they use underscored capitals
as a second case (rather like early Unix would use A and \A).  In the
case of APL, I suspect the limiting factor was the number of characters
on a golfball.  Internally, it required 8-bit characters to represent
all the symbols.

>Capitalization can improve legibility in
>written languages but the meaning of a word often doesn't
>change in spite of case change. In modern PLs the meaning can
>be entirely different, and even the category (DO vs do) and I
>am not sure that increases legibility.

Cases (particularly capitalisation) can add meaning - German and English
both use capitalisation as hints (I'm not sure about other languages).
Many programming languages have defacto conventions that use case to
indicate the category of a name (eg constants and macros are all upper
case in C) and Go uses capitalisation to control visibility.

The problem of "DO" vs "do" is no different to "xl" vs "x1" vs "xI" or
"DO" vs "D0" - they are distinct to the compiler but can be confusing to
the reader and are probably better handled via style conventions than
trying to mandate that the compiler makes them equivalent.

>Not to mention the
>camelCaseHorror. Much prefer hyphenated-words

Hyphenated variable names don't work in many programming languages
because "-" is an operator.  The use of camelCase vs underscores tends
to be a language convention.  Whe

Using "case-insensitive, case-preserving" helps in some cases but I
suspect at least some of that is because that is mostly how English
works and therefore English speakers will naturally read "THIS" and
"this" as equivalent.  Someone whose native language is not a latin
script is likely to find having "THIS" and "this" being the same is
quite confusing and an English speaker probably won't instinctively
see "jqvkwrri" and "JQVKWRRI" as identical.  (BTW, DNS is an example
of a case-insensitive, case-preserving service).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180407/340e7861/attachment.sig>

[TUHS] long lived programs

[Paul Winalski]

On 4/5/18, Norman Wilson <norman at oclsc.org> wrote:

[regarding streams implementation of pipes]
>
> But the System V folks were very nervous about it anyway, and
> wrote a planning document in which they proposed to create a
> new, different system call to make stream pipes.  pipe(2) would
> make an old-fashioned pipe; spipe(2) (or whatever it was called,
> I forget the name) had to be called to get a stream.  The document
> didn't really explain the justification for this.  To us in
> Research it just sounded crazy.

Sometimes critical code can have unintended dependencies on buggy or
undocumented behavior of system features.  I ran into something of
this sort in the Unix C runtime when I did the linker for VAX Fortran
for Ultrix.  The VAX Fortran runtime was written in several source
languages, and there was no common back end for the compilers for
these languages, so we decided that the easiest way to get the whole
mess ported to Ultrix was to port the VAX/VMS linker to Ultrix and to
teach it to understand a.out files and ar archives.  To prevent any
copyright or other IP problems, we did the project without reference
to the Unix sources or anything other than publicly published
documents.

All went well until we got to testing, where we got a curious test
failure.  The cause of the failure was the allocation of the C RTL's
iob structure, which is an array that holds the file descriptors
associated with stdin, stdout, and stderr.  The program was dying
because it was accessing iob[2] (stderr), but my Ultrix linker had
only allocated 8 bytes, not 12, for the iob array.  ld, on the other
hand, allocated 12 bytes.  All of the objects that participated in the
link had iob declared as an 8-byte common symbol, so I couldn't for
the life of me understand why ld allocated 12 bytes for it.

In desperation I looked at the source code for ld.  a.out common
symbols have the "external" bit specified, but unlike global reference
symbols they have a non-zero value field.  If there is a global
definition for the name, the common symbol is resolved against that
(i.e., it behaves like a global reference).  If not, the linker
allocates space in bss for the symbol, using the value field as the
number of bytes to allocate.  If common symbols of the same name from
different object files have different sizes, the linker allocates the
largest size.  The other significant feature of common symbols is that
if an archive member contains a common symbol that resolves a global
reference, that isn't enough to cause the archive member to be loaded,
as would be the case with a global definition.

The root cause of my problem was a feature of the ranlib program.
When ranlib built the archive index of global symbols, it merely
looked at the "external" bit--it indexed common symbols as well as
global definitions.  So if a linker sees a name it's looking for in
the ranlib index, it has to actually process the module's symbol table
to make sure that it is a "hard" definition and not a common symbol.
My ported VMS linker was very careful to do a pre-scan of each module
before loading so as to prevent common symbols causing a load.  ld
took a different approach--it loaded the module and then processed its
symbol table.  If it found that a common symbol had provoked the load,
it said "oops" and unloaded the module.  But by then it had already
maximized the sizes of any common symbols that were in the module--the
new sizes didn't get backed out.  So for common symbols ld would
allocate not the largest size for the symbol in any module
participating in the link, but the largest size IN ANY MODULE THAT LD
SAW while doing the link!

It turned out that there was a module in the Unix C runtime declared
iob as a two-element array, but the code accessed iob[2].  They got
away with this bug because ld always saw modules where iob was a
three-element array when it processed libc.a and thus always allocated
12 bytes for it.  My linker processed only the symbols in the modules
that actually were brought in from libc.a, and hence it ended up
allocating only 8 bytes.

One of Murphy's laws of programming is that if a facility has
undocumented side effects, there will be an important program that
depends on them.  Hence the reluctance of many software engineers to
make radical changes to how a feature is implemented.

-Paul W.

[TUHS] long lived programs

[Larry McVoy]

On Fri, Apr 06, 2018 at 09:01:44PM -0400, Paul Winalski wrote:
> Last year I bought two 4 TB drives for backing up my home computer.
> As I walked to the check-out, it occurred to me that I was holding in
> my hands over a thousand times the entire disk capacity of the world
> at the time I started in the industry.

Yeah, it's crazy.  When I was doing my first sys admin job it was on a
Masscomp that had a 40MB disk for 20 people.  We made it work.

I believe someone announced a 40TB SSD, nope, just looked, Seagate announced
a 60TB SSD in 2016.  WTF, that's a huge drive for rotating, that's insane 
for SSD.

We old farts live in interesting times.

--lm

[TUHS] long lived programs

[Paul Winalski]

On 4/6/18, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>
The washing-machine
> sized machine could be driven to walk across the floor.

I had exactly that happen to me when I was a student operator of my
college's System/360.  We had a bank of three IBM 2311 disk drives
(each washing machine size; capacity 7 MB).  They were bolted together
and at the opposite end of the raised floor computer room from the CPU
and operator's station.  Facing the console, I had my back to the disk
drives.  One evening I heard rattling noises behind me, turned my
chair around, and was shocked to find the disk drives right behind me.
IBM customer service had forgotten to lock the wheels on the drives,
and they had crept across the floor.

> Vic Vyssotsky calculated that with only
> 10 times its 10MB capacity, we could have kept the entire printed
> output since the advent of computers at the Labs on line.

Last year I bought two 4 TB drives for backing up my home computer.
As I walked to the check-out, it occurred to me that I was holding in
my hands over a thousand times the entire disk capacity of the world
at the time I started in the industry.

-Paul W.

[TUHS] long lived programs

[Doug McIlroy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

> Shortly after I arrived, the comp center announced a
brand-new feature -- permanent disc storage!  (actually, I think it
was a drum...)

Irrelevant to the story (or Unix), but it was indeed a disc drive--much
more storage per unit volume than drums, which date to the 1940s, if
not before. Exact opposite of current technology: super heavy and
rigid combs banged in and out of the disk stack. The washing-machine
sized machine could be driven to walk across the floor. It would not
be nice to be caught in its path. (Fortunately ordinary work loads
did not have such an effect.) Vic Vyssotsky calculated that with only
10 times its 10MB capacity, we could have kept the entire printed
output since the advent of computers at the Labs on line.

Doug

[TUHS] long lived programs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On Fri, Mar 23, 2018 at 4:50 PM, Steve Johnson <scj at yaccman.com> wrote:

> Another issue to consider.  I once talked with someone who was designing
> nuclear reactors.  They had a similar requirement to archive their design
> simulations.  But in this case, part of the requirement was to pass some
> standard simulation tests (in FORTRAN, of course).  He was complaining that
> these programs had bugs and didn't give the right answer.   So they ran the
> corrected programs to make sure the thing would not blow up, and then
> tweaked their parameters so it would pass the buggy program that was
> written into law...
>
> Steve
>

​That's not Fortran's problem -- that is our legal system.​

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/4e169ddf/attachment.html>

[TUHS] long lived programs

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

Another issue to consider.  I once talked with someone who was
designing nuclear reactors.  They had a similar requirement to
archive their design simulations.  But in this case, part of the
requirement was to pass some standard simulation tests (in FORTRAN, of
course).  He was complaining that these programs had bugs and didn't
give the right answer.   So they ran the corrected programs to make
sure the thing would not blow up, and then tweaked their parameters so
it would pass the buggy program that was written into law...

Steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/f34081d8/attachment-0001.html>

[TUHS] long lived programs

[Steve Nickolas]

On Fri, 23 Mar 2018, Lawrence Stewart wrote:

> Suppose we define a machine architecture not for building hardware, but 
> specifically for itself being easy to emulate?
>
> This is by analogy to para-virtualized device drivers, which are not 
> there to model real devices, but to be easy to support in a virtual 
> machine environment.

I've had an idea to create a sort of idealized VM for running C in (like a 
JVM designed specifically for C) and a full VM-OS type thing as well - but 
I couldn't figure out how to go about implementing it.  Still...sounds 
similar to what you propose, which might not be a bad idea.

-uso.

[TUHS] long lived programs

[Lawrence Stewart]

Suppose we define a machine architecture not for building hardware, but specifically for itself being easy to emulate?

This is by analogy to para-virtualized device drivers, which are not there to model real devices, but to be easy to support in a virtual machine environment.
 

> On 2018, Mar 23, at 12:25 PM, Lars Brinkhoff <lars at nocrew.org> wrote:
> 
> Clem Cole wrote:
>> Ron Natalie wrote:
>>> The bigger issue than software getting obsoleted is that the platform
>>> needed to run it goes away. 
>> 
>> Although simh is huge step in that direction ;)
> 
> I imagine a future where SIMH itself only runs on obsolete platforms and
> has to be run inside an emulator.  Repeat, etc etc.

[TUHS] long lived programs

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

➢ Although simh is huge step in that direction ;)
 
Yep, sometimes that's the easier solution.    Remember the old Honeywell IMPs.     BBN wanted to move forward, but all the code was in 516 emulators (having been ported over from the PDP-1, they should have realized that portability would be important).   They built the C-30 to emulate the Honeywell.

Of course, this isn't even accounting for the VAX emulating the PDP and the like.

You do find some relics still running stuff.    I remember seing a new computer being installed at some FAA facilities.   It was some Apollo systems long after HP had pulled the plug on the DomainOS and the related hardware. 

I still remember a while when we were in the business of porting/selling MOTIF on a wide variety of platforms.    One day, the reps from Stellar insisted they need their loaner machine back.   This was a trade show unit and had an huge anvil shipping case.    I packed it up and put it on our loading dock.    The next day Stellar announced they were out of business.   I didn't think anything about it for a couple of years when I went out to our loading dock and said "Is this stupid thing still here."   They had never come for it.   I then was called into our sales manager's office.    Some guy needs a MOTIF for a Stellar.    I chuckle.    He goes "Yeah I know they're out of business."   I tell him that today's his lucky day.   I still have one.   I uncrated the thing, wrote him out a tape, and packed it back up.    Last I saw one of the CPU boards was hanging on the wall of our conference room as a decoration and another programmer and ripped out the Wyse PC the thing had in the top of it as a boot-up/maintenance processor to take home.

[TUHS] long lived programs

[Lars Brinkhoff]

Clem Cole wrote:
> Ron Natalie wrote:
>>  The bigger issue than software getting obsoleted is that the platform
>>  needed to run it goes away. 
>
> Although simh is huge step in that direction ;)

I imagine a future where SIMH itself only runs on obsolete platforms and
has to be run inside an emulator.  Repeat, etc etc.

[TUHS] long lived programs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On Fri, Mar 23, 2018 at 11:51 AM, Ron Natalie <ron at ronnatalie.com> wrote:

>
> The bigger issue than software getting obsoleted is that the platform
> needed to run it goes away.
>
​+1

Although simh is huge step in that direction ;)
​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/065f6c5d/attachment.html>

[TUHS] long lived programs

[Ron Natalie]

A core package in a lot of the geospatial applications is a old piece of
mathematical code originally written in Fortran (probably in the sixties).
Someone probably in the 80's recoded the thing pretty much line for line
(maintaining the horrendous F66 variable names etc.) into C.     It's
probably ripe for a jump to something else now.

 

We've been through four major generations of the software.    The original
was all VAX based with specialized hardware (don't know what it was written
in).    We followed that on with a portable UNIX (but mostly Suns, but ours
worked on SGI, Ardent, Stellar, various IBM AIX platofrms, Apollo DN1000's,
HP, DEC Alphas).   This was primarily a C application.    Then right about
the year 2000, we jumped to C++ on Windows.    Subsequently it got back
ported to Linux.     Yes there are some modules that have been unchanged for
decades, but the system on the whole has been maintained.

 

The bigger issue than software getting obsoleted is that the platform needed
to run it goes away.   

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180323/a6ab4cdb/attachment.html>