[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[Rudi Blom]

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

> Date: Sat, 30 Jul 2016 15:30:36 +0000
> From: Michael Kjörling <michael at kjorling.se>
> To: tuhs at tuhs.org
> Subject: Re: [TUHS] History repeating itself
> Message-ID: <20160730153036.GI3375 at yeono.kjorling.se>
> Content-Type: text/plain; charset=utf-8
>
> On 30 Jul 2016 10:15 -0400, from cowan at mercury.ccil.org (John Cowan):
>>> Who needs FedEx?
>>
>> Well, latency counts for something too, as does radius: if I want to
>> send bulk data from New York to London (a very normal thing to do),
>> your station wagon isn't going to count for much.
>
> You could, however, get an economy class flight ticket and load up
> your suitcase with either HDDs or SDXCs (I suspect SDXCs would be
> better per amount of data from the perspective of both volume and
> weight, and would take better to handling). Given FedEx's prices,
> _once you have the infrastructure set up_ (which you'll need whether
> you have someone travel with the media, by air or by stationwagon, or
> FedEx it), that _might_ even compare favorably in terms of bytes
> transferred per second per dollar. (Now that's a measurement of
> throughput I don't think I've seen before; B/s/$.) Of course, you'd
> need someone who can babysit the suitcase, which potentially adds to
> the cost, but the stationwagon traditionally hasn't been self-driving
> either, and most of a transatlantic flight isn't active time on part
> of the person travelling with the suitcase so you could go with an
> overnight flight and allow the person to sleep.
>
> If you want to reduce the risk of the bag getting handled roughly or
> lost in handling, reduce the above to carry-on luggage; it will still
> provide a quite respectable throughput.
>
> ... ...
>
> It might not be the absolute cheapest approach, but it seems rather
> hard to beat in terms of throughput per dollar for bulk data transfer,
> especially if you already have someone who would travel anyway and can
> be convinced to take a company-approved suitcase in return for having
> their ticket paid for.
>
> --
> Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
>                  “People who think they know everything really annoy
>                  those of us who know we don’t.” (Bjarne Stroustrup)
>

To setup the 'infrastructure might be the tricky part. Many years ago
I flew from Montreal to Amsterdam and had two stacks of 5-1/4"
diskettes with me. No papers, confiscated in Amsterdam.

Cheers,
Rudi

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[John Cowan]

Rudi Blom scripsit:

> To setup the 'infrastructure might be the tricky part. Many years ago
> I flew from Montreal to Amsterdam and had two stacks of 5-1/4"
> diskettes with me. No papers, confiscated in Amsterdam.

I carried an RK05 disk full of proprietary software from West Orange NJ
to a client in Kansas City back in 1977.  Airport security existed, but
it wasn't as anal it is today.  So when I told them they couldn't X-ray
the disk, it might scramble it, they wanted to do a physical inspection --
but I told them if they opened the disk they'd get dust in it and ruin it.
Finally they took my word for it.

When the disk got to the client's, it was completely scrambled anyway.
I went back home, and next week my partner went out with a stack of 5.25s.
It took him twenty hours to set up the client's system (I don't remember
if it was a PDP-8 or a PDP-11), but the job got done.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
But no living man am I!  You look upon a woman.  Eowyn I am, Eomund's daughter.
You stand between me and my lord and kin.  Begone, if you be not deathless.
For living or dark undead, I will smite you if you touch him.

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[Rudi Blom]

My 'incident' was around 1985 if I remember correctly. A time people
and border guards started to realise the possible value of what was on
such funny things like diskettes. Also I crossed 'National' borders.
Now that can be tricky even today :-)


On 01/08/2016, John Cowan <cowan at mercury.ccil.org> wrote:
>
> I carried an RK05 disk full of proprietary software from West Orange NJ
> to a client in Kansas City back in 1977.  Airport security existed, but
> it wasn't as anal it is today.  So when I told them they couldn't X-ray
> the disk, it might scramble it, they wanted to do a physical inspection --
> but I told them if they opened the disk they'd get dust in it and ruin it.
> Finally they took my word for it.
>
> When the disk got to the client's, it was completely scrambled anyway.
> I went back home, and next week my partner went out with a stack of 5.25s.
> It took him twenty hours to set up the client's system (I don't remember
> if it was a PDP-8 or a PDP-11), but the job got done.
>

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[scj]

> My 'incident' was around 1985 if I remember correctly. A time people
> and border guards started to realise the possible value of what was on
> such funny things like diskettes. Also I crossed 'National' borders.
> Now that can be tricky even today :-)
>
A Canadian friend of mine, after working in the US for five or so years,
was returning to Canada about 1969 with five years of research in 20 or 30
boxes of punched cards in the back of his car.  He was stopped at the
border and told that he would have to pay duty on the card boxes -- I
think the total came to over $200.  He argued with them for some time, and
finally one of the agents opened one of the boxes and said "Oh!  These are
USED punch cards!  There is no duty."

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[Clem Cole]

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

On Mon, Aug 1, 2016 at 1:11 PM, <scj at yaccman.com> wrote:

>  "Oh!  These are
> ​ ​
> USED punch cards!  There is no duty."
>
>
​For a long time, Canada was trying to tax software going over the border,
as well as some equipment.   When Kelly Booth was at Waterloo, he had 5
1/2" tapes with special stamps from the Canadian Gov he had to use to carry
things after having had tapes confiscated.   The funny part was you could
physically mail the tape, but if you tried to bring them personally; it was
an issue.   Kelly told me if they have been unopened and new it would not
have been an issue - but it was that it they were used that tended cause
issues.

I also remember getting a system ready for the Toronto USENIX.   It was
amazing the paper we needed, and had to prove we were not going to sell the
system there etc.

Clem

Clem

The problem was putting a value on things.   So they were marked as
research data IIRC, which
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160801/c1e54ad0/attachment.html>

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[Dave Horsfall]

On Mon, 1 Aug 2016, scj at yaccman.com wrote:

> A Canadian friend of mine, after working in the US for five or so years,
> was returning to Canada about 1969 with five years of research in 20 or 30
> boxes of punched cards in the back of his car.  He was stopped at the
> border and told that he would have to pay duty on the card boxes -- I
> think the total came to over $200.  He argued with them for some time, and
> finally one of the agents opened one of the boxes and said "Oh!  These are
> USED punch cards!  There is no duty."

Not Henry Spencer, perchance?

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

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[Norman Wilson]

Dave Horsfall:

  Not Henry Spencer, perchance?

=====

Since the Canadian in question had been working in the US since
1964 or so, he must by now be pushing 70 years old.

I haven't seen Henry for some years, but I don't think he has
aged that much.

Norman Wilson
Toronto ON

[TUHS] Unix v6 problem with /tmp

[Mark Longridge]

Hi folks,

My root partition for Unix v6 is almost full and /dev/rk0 only has 83 blocks.

The trouble is I wanted to compile bc.y and I think it needs around
300 blocks of temporary space. I was wondering if there was a way to
set up Unix v6 so that it could use one of the other drives for tmp
space. I tried to set up a link using ln but it seems I can't link
across filesystems.

The exact error is "26: Intermediate file error".

I managed to rearrange things so that /dev/rk0 had over 300 blocks of
free space and it fixed the problem, but I'm curious if there was
another solution.

Mark

[TUHS] Unix v6 problem with /tmp

[William Pechter]

Mark Longridge wrote:
> Hi folks,
>
> My root partition for Unix v6 is almost full and /dev/rk0 only has 83 blocks.
>
> The trouble is I wanted to compile bc.y and I think it needs around
> 300 blocks of temporary space. I was wondering if there was a way to
> set up Unix v6 so that it could use one of the other drives for tmp
> space. I tried to set up a link using ln but it seems I can't link
> across filesystems.
>
> The exact error is "26: Intermediate file error".
>
> I managed to rearrange things so that /dev/rk0 had over 300 blocks of
> free space and it fixed the problem, but I'm curious if there was
> another solution.
>
> Mark
Ah the good old days before BSD's symlinks.
Only thing I can think of is add another drive or partition and mount it
as /tmp.


Bill

[TUHS] Unix v6 problem with /tmp

[Clem Cole]

That is exactly how its was done.   In fact, DEC made a Solid State Disk
(out of RAM) just for UNIX that people used to use for /tmp.


Also to be fair, Dennis did symlinks before 4.2.   They were part of the V8
I believe.  I remember talking to him and Steve Bourne about them and ideas
in the FS.  Dennis's basic thesis was that while UNIX had a typed file
system, he & Ken intentionally kept the number of types very very small.
 The problem he was afraid of what that too many systems had ended up so
many different ways to handle things.    Just keep everything as a ASCII
text file and let the user space deal with it.   Symlinks, or "late name
binding" for the FS was a mixed bag.    Just as Dennis predicted, Solaris
was an example of an implementation that went symlink happy.

I created Conditionally Dependant Symlinks (CDSL) which I think only showed
up in Masscomp's RTU, Stellix and Tru64.   The were not only late binding,
but added the concept of a user settable context.   Very handy when trying
to create a "single system image" from multiple system.   I miss them today
from Linux clusters and even put them back into one of my systems.   B


Also, around the same time that Dennis added symlinks, Apollo's Aegis (aka
Domain) guys came up with a cool idea where you can run application code
from a link - extensible types.    I remember talking to Dennis and Ken
about them at a SOSP IIRC, and toyed with putting them into one of the
Locus UNIX Kernels.   We proposed it for HP-UX and Tru64, but never got
funded to try it, although I think / believe others did some where else.



On Wed, Jul 27, 2016 at 4:31 PM, William Pechter <pechter at gmail.com> wrote:

> Mark Longridge wrote:
> > Hi folks,
> >
> > My root partition for Unix v6 is almost full and /dev/rk0 only has 83
> blocks.
> >
> > The trouble is I wanted to compile bc.y and I think it needs around
> > 300 blocks of temporary space. I was wondering if there was a way to
> > set up Unix v6 so that it could use one of the other drives for tmp
> > space. I tried to set up a link using ln but it seems I can't link
> > across filesystems.
> >
> > The exact error is "26: Intermediate file error".
> >
> > I managed to rearrange things so that /dev/rk0 had over 300 blocks of
> > free space and it fixed the problem, but I'm curious if there was
> > another solution.
> >
> > Mark
> Ah the good old days before BSD's symlinks.
> Only thing I can think of is add another drive or partition and mount it
> as /tmp.
>
>
> Bill
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160727/cc4540f6/attachment.html>

[TUHS] Unix v6 problem with /tmp

[William Pechter]

Clem Cole wrote:
> That is exactly how its was done.   In fact, DEC made a Solid State 
> Disk (out of RAM) just for UNIX that people used to use for /tmp.
>
Are you referring to the slick little ML11-A  (I think it was an -A when 
I installed it at NY Telephone on
West Street, next to the World Trade Center...

I seem to remember it being used as an RS04 (or similar) fixed head disk 
replacement for swap -- but
it could've been used for temp.

Funny seeing a fault light on a Massbus controller'd box of mostly MK11 
memory.
IIRC it had write-lock as well.

Neat idea and I wish someone would come up with a really large SSD with 
a writelock for archival storage
of my stuff.  No head crashes and if I could disable the possibility of 
accidental writing...

Bill

-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/

[TUHS] Unix v6 problem with /tmp

[Clem cole]

Yep.  We used it for both but discovered it tended to be better for our system as a /tmp because we tried really hard to keep the 11/70 from swapping in those days. 

Clem

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Jul 27, 2016, at 5:10 PM, William Pechter <pechter at gmail.com> wrote:
> 
> Clem Cole wrote:
>> That is exactly how its was done.   In fact, DEC made a Solid State Disk (out of RAM) just for UNIX that people used to use for /tmp.
> Are you referring to the slick little ML11-A  (I think it was an -A when I installed it at NY Telephone on
> West Street, next to the World Trade Center...
> 
> I seem to remember it being used as an RS04 (or similar) fixed head disk replacement for swap -- but
> it could've been used for temp.
> 
> Funny seeing a fault light on a Massbus controller'd box of mostly MK11 memory.
> IIRC it had write-lock as well.
> 
> Neat idea and I wish someone would come up with a really large SSD with a writelock for archival storage
> of my stuff.  No head crashes and if I could disable the possibility of accidental writing...
> 
> Bill
> 
> -- 
> Digital had it then.  Don't you wish you could buy it now!
> pechter-at-gmail.com  http://xkcd.com/705/
> 

[TUHS] Unix v6 problem with /tmp

[William Pechter]

Clem cole wrote:
> Yep.  We used it for both but discovered it tended to be better for our system as a /tmp because we tried really hard to keep the 11/70 from swapping in those days. 
>
> Clem
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

That gave the AT&T folks (and Regional Bells) a major improvement over
the RS04 (and less of a maintenance problem) and the Computer Special
Systems folks at DEC had a way to use less than perfect MK11 memory
since the embedded internal ML11 disk controller mapped out bad blocks
in NVRAM  so it looked like a clean disk. I remember stories about a 3x
improvement in some of the 11/70's jobs,

I don't know what apps were on the box.  Might have been COSMOS or
something else.

When I saw the Windows Ready Boost and Intel Turbo memory I really
flashed (ugh pun not intended) to the day I installed the early
ML11... Nothing new in the OS business that wasn't done in the old
days.  Unfortunately, there's very little love for history in the industry.
My college major was history... so I love the connected nature of the
designs.  It's all an evolution.


Bill
>> On Jul 27, 2016, at 5:10 PM, William Pechter <pechter at gmail.com> wrote:
>>
>> Clem Cole wrote:
>>> That is exactly how its was done.   In fact, DEC made a Solid State Disk (out of RAM) just for UNIX that people used to use for /tmp.
>> Are you referring to the slick little ML11-A  (I think it was an -A when I installed it at NY Telephone on
>> West Street, next to the World Trade Center...
>>
>> I seem to remember it being used as an RS04 (or similar) fixed head disk replacement for swap -- but
>> it could've been used for temp.
>>
>> Funny seeing a fault light on a Massbus controller'd box of mostly MK11 memory.
>> IIRC it had write-lock as well.
>>
>> Neat idea and I wish someone would come up with a really large SSD with a writelock for archival storage
>> of my stuff.  No head crashes and if I could disable the possibility of accidental writing...
>>
>> Bill
>>
>> -- 
>> Digital had it then.  Don't you wish you could buy it now!
>> pechter-at-gmail.com  http://xkcd.com/705/
>>

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[Michael Kjörling]

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

On 27 Jul 2016 21:03 -0400, from pechter at gmail.com (William Pechter):
> When I saw the Windows Ready Boost and Intel Turbo memory I really
> flashed (ugh pun not intended) to the day I installed the early
> ML11... Nothing new in the OS business that wasn't done in the old
> days.  Unfortunately, there's very little love for history in the industry.

I remember when this newfangled thing called "the cloud" started
becoming _the_ thing that was being talked about recently, and I kept
asking myself how on Earth that's anything new. Large timeshared
systems fell out of favor basically when local systems with adequate
storage and processing capabilities became affordable, and now large
timeshared systems - under a different name, mind you, because history
does not repeat itself, it rhymes - have become favorable again
(despite the fact that essentially _any_ desktop system today has
processing capabilities not entirely dissimilar to a supercomputer of
twenty years ago). But this time, very often it's _actually_ _someone
else's computer_; it's not just sitting in some other department
within the company. I'll admit, it's awfully convenient at times, but
it's hardly something _new_.

Now all that's really missing is that stationwagon loaded with tapes
for regular large-scale data transfer, and with some of the
discussions going on in the last few years I wouldn't be the least bit
surprised if sneakernet has seen a rebound at least in some places.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[Tony Finch]

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

Michael Kjörling <michael at kjorling.se> wrote:
>
> Now all that's really missing is that stationwagon loaded with tapes
> for regular large-scale data transfer, and with some of the
> discussions going on in the last few years I wouldn't be the least bit
> surprised if sneakernet has seen a rebound at least in some places.

https://aws.amazon.com/importexport/disk/ :-)

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
South Fitzroy: Northerly 5 to 7. Moderate or rough. Fair. Good.

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[John Cowan]

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

Michael Kjörling scripsit:

> But this time, very often it's _actually_ _someone
> else's computer_; it's not just sitting in some other department
> within the company. 

Nothing new about that either:  "service bureaus" have been around a
long time, notably for APL\360.

> Now all that's really missing is that stationwagon loaded with tapes

Now replaced by the Fedexed hard drive.  Xkcd estimates that if they did
nothing else, Fedex would be able to transmit 14 petabits per second.
Companies dealing in big data often use this internally, and IIRC you
can donate content to the Internet Archive by sending them a disk.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
At times of peril or dubitation,
Perform swift circular ambulation,
With loud and high-pitched ululation.

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[Greg 'groggy' Lehey]

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

On Thursday, 28 July 2016 at  9:57:40 -0400, John Cowan wrote:
> Michael Kjörling scripsit:
>>
>> Now all that's really missing is that stationwagon loaded with tapes
>
> Now replaced by the Fedexed hard drive.  Xkcd estimates that if they did
> nothing else, Fedex would be able to transmit 14 petabits per second.
> Companies dealing in big data often use this internally, and IIRC you
> can donate content to the Internet Archive by sending them a disk.

Hard disk drives are yesterday's criterion.  Now it's microSDXC cards.
Physical volume 0.165 ml, up to 200 GB.  I've seen claims that my
station wagon has a cargo volume of 2,752 l, though that seems on the
high side.  That corresponds to about 16,670,000 cards or 3.3 EB.
Take that on a 20 minute drive, and you end up with a link bandwidth
of about 22 Pb/s.

Who needs FedEx?  Of course, the link bandwidth is no longer the
bottleneck.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160730/4ad628f7/attachment.sig>

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[William Cheswick]

> On 30Jul 2016, at 3:56 AM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> 
> Take that on a 20 minute drive, and you end up with a link bandwidth
> of about 22 Pb/s.

Of course, those cards take time to fill and empty, which should be part of the bandwidth
computation.

I was astonished to learn that one of those pinky-sized micro-SD cards has 33 circuit boards
in it, stacked in a staggered formation.  32 have memory, one a fairly powerful CPU.

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[Greg 'groggy' Lehey]

On Saturday, 30 July 2016 at  7:41:39 -0400, William Cheswick wrote:
>
>> On 30Jul 2016, at 3:56 AM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
>>
>> Take that on a 20 minute drive, and you end up with a link bandwidth
>> of about 22 Pb/s.
>
> Of course, those cards take time to fill and empty, which should be
> part of the bandwidth computation.

It's certainly part of the overall bandwidth computation, but not of
the link bandwidth.  That was my point.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160731/6db0618e/attachment.sig>

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[scj]

A "standard" 80-column punched card held 80 12-bit columns, or 120 bytes.
1000 cards stacked up took roughly a foot, to get 120,000 bytes
So to store a megabyte would take about 8 1/3 feet of cards.
A gigabyte would be over a mile and a half high.
A terabyte would be over 1500 miles high (half the width of the USA)
A petabyte stack would be over six times the distance to the moon...

Exponential growth may seem like business as normal today, but in reality,
it boggles the mind...

Steve


>>
>> Of course, those cards take time to fill and empty, which should be
>> part of the bandwidth computation.

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[Tony Finch]

William Cheswick <ches at cheswick.com> wrote:
>
> I was astonished to learn that one of those pinky-sized micro-SD cards
> has 33 circuit boards in it, stacked in a staggered formation.  32 have
> memory, one a fairly powerful CPU.

I don't think they have what I would call a circuit board inside: the
microSD card is itself a multi-chip package.

http://www.bunniestudios.com/blog/?page_id=1022

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: North or northwest 4 or 5, increasing 6 at times. Slight or
moderate. Fair. Good.

[TUHS] History repeating itself (was: Unix v6 problem with /tmp)

[John Cowan]

Greg 'groggy' Lehey scripsit:

> Who needs FedEx?  

Well, latency counts for something too, as does radius: if I want to
send bulk data from New York to London (a very normal thing to do),
your station wagon isn't going to count for much.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Pour moi, les villes du Silmarillion ont plus de realite que Babylone.
                --Christopher Tolkien, as interviewed by Le Monde