* [TUHS] Unix v6 problem with /tmp @ 2016-07-27 20:28 Mark Longridge 2016-07-27 20:31 ` William Pechter 0 siblings, 1 reply; 22+ messages in thread From: Mark Longridge @ 2016-07-27 20:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] Unix v6 problem with /tmp 2016-07-27 20:28 [TUHS] Unix v6 problem with /tmp Mark Longridge @ 2016-07-27 20:31 ` William Pechter 2016-07-27 20:57 ` Clem Cole 0 siblings, 1 reply; 22+ messages in thread From: William Pechter @ 2016-07-27 20:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] Unix v6 problem with /tmp 2016-07-27 20:31 ` William Pechter @ 2016-07-27 20:57 ` Clem Cole 2016-07-27 21:01 ` Clem Cole ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Clem Cole @ 2016-07-27 20:57 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] Unix v6 problem with /tmp 2016-07-27 20:57 ` Clem Cole @ 2016-07-27 21:01 ` Clem Cole 2016-07-27 21:10 ` William Pechter 2016-07-28 23:16 ` [TUHS] environments/universes (was: Unix v6 problem with /tmp) Sven Mascheck 2 siblings, 0 replies; 22+ messages in thread From: Clem Cole @ 2016-07-27 21:01 UTC (permalink / raw) BTW: Mark if you are running on a simulator, just create an extra drive in the RK05 driver, put 4280 blocks on it and mount it on /tmp in /etc/rc when you go multi-user. You should be all set, and you will be running like many/most V6 and V7 systems in years gone by. On Wed, Jul 27, 2016 at 4:57 PM, Clem Cole <clemc at ccc.com> 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. > > > 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/7acc6cf3/attachment-0001.html> ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] Unix v6 problem with /tmp 2016-07-27 20:57 ` Clem Cole 2016-07-27 21:01 ` Clem Cole @ 2016-07-27 21:10 ` William Pechter 2016-07-28 0:49 ` Clem cole 2016-07-28 1:03 ` [TUHS] Unix v6 problem with /tmp Clem cole 2016-07-28 23:16 ` [TUHS] environments/universes (was: Unix v6 problem with /tmp) Sven Mascheck 2 siblings, 2 replies; 22+ messages in thread From: William Pechter @ 2016-07-27 21:10 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] Unix v6 problem with /tmp 2016-07-27 21:10 ` William Pechter @ 2016-07-28 0:49 ` Clem cole 2016-07-28 1:03 ` William Pechter 2016-07-28 1:03 ` [TUHS] Unix v6 problem with /tmp Clem cole 1 sibling, 1 reply; 22+ messages in thread From: Clem cole @ 2016-07-28 0:49 UTC (permalink / raw) 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/ > ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] Unix v6 problem with /tmp 2016-07-28 0:49 ` Clem cole @ 2016-07-28 1:03 ` William Pechter 2016-07-28 11:23 ` [TUHS] History repeating itself (was: Unix v6 problem with /tmp) Michael Kjörling 0 siblings, 1 reply; 22+ messages in thread From: William Pechter @ 2016-07-28 1:03 UTC (permalink / raw) 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/ >> ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] History repeating itself (was: Unix v6 problem with /tmp) 2016-07-28 1:03 ` William Pechter @ 2016-07-28 11:23 ` Michael Kjörling 2016-07-28 12:18 ` Tony Finch 2016-07-28 13:57 ` John Cowan 0 siblings, 2 replies; 22+ messages in thread From: Michael Kjörling @ 2016-07-28 11:23 UTC (permalink / raw) [-- 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) ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] History repeating itself (was: Unix v6 problem with /tmp) 2016-07-28 11:23 ` [TUHS] History repeating itself (was: Unix v6 problem with /tmp) Michael Kjörling @ 2016-07-28 12:18 ` Tony Finch 2016-07-28 13:57 ` John Cowan 1 sibling, 0 replies; 22+ messages in thread From: Tony Finch @ 2016-07-28 12:18 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] History repeating itself (was: Unix v6 problem with /tmp) 2016-07-28 11:23 ` [TUHS] History repeating itself (was: Unix v6 problem with /tmp) Michael Kjörling 2016-07-28 12:18 ` Tony Finch @ 2016-07-28 13:57 ` John Cowan 2016-07-30 7:56 ` Greg 'groggy' Lehey 1 sibling, 1 reply; 22+ messages in thread From: John Cowan @ 2016-07-28 13:57 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] History repeating itself (was: Unix v6 problem with /tmp) 2016-07-28 13:57 ` John Cowan @ 2016-07-30 7:56 ` Greg 'groggy' Lehey 2016-07-30 11:41 ` William Cheswick 2016-07-30 14:15 ` John Cowan 0 siblings, 2 replies; 22+ messages in thread From: Greg 'groggy' Lehey @ 2016-07-30 7:56 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] History repeating itself (was: Unix v6 problem with /tmp) 2016-07-30 7:56 ` Greg 'groggy' Lehey @ 2016-07-30 11:41 ` William Cheswick 2016-07-30 23:28 ` Greg 'groggy' Lehey 2016-08-01 11:36 ` Tony Finch 2016-07-30 14:15 ` John Cowan 1 sibling, 2 replies; 22+ messages in thread From: William Cheswick @ 2016-07-30 11:41 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] History repeating itself (was: Unix v6 problem with /tmp) 2016-07-30 11:41 ` William Cheswick @ 2016-07-30 23:28 ` Greg 'groggy' Lehey 2016-07-30 23:50 ` scj 2016-08-01 11:36 ` Tony Finch 1 sibling, 1 reply; 22+ messages in thread From: Greg 'groggy' Lehey @ 2016-07-30 23:28 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] History repeating itself (was: Unix v6 problem with /tmp) 2016-07-30 23:28 ` Greg 'groggy' Lehey @ 2016-07-30 23:50 ` scj 0 siblings, 0 replies; 22+ messages in thread From: scj @ 2016-07-30 23:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] History repeating itself (was: Unix v6 problem with /tmp) 2016-07-30 11:41 ` William Cheswick 2016-07-30 23:28 ` Greg 'groggy' Lehey @ 2016-08-01 11:36 ` Tony Finch 1 sibling, 0 replies; 22+ messages in thread From: Tony Finch @ 2016-08-01 11:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] History repeating itself (was: Unix v6 problem with /tmp) 2016-07-30 7:56 ` Greg 'groggy' Lehey 2016-07-30 11:41 ` William Cheswick @ 2016-07-30 14:15 ` John Cowan 2016-07-30 15:30 ` [TUHS] History repeating itself Michael Kjörling 1 sibling, 1 reply; 22+ messages in thread From: John Cowan @ 2016-07-30 14:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] History repeating itself 2016-07-30 14:15 ` John Cowan @ 2016-07-30 15:30 ` Michael Kjörling 0 siblings, 0 replies; 22+ messages in thread From: Michael Kjörling @ 2016-07-30 15:30 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2805 bytes --] 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. If carry-on allows 10 kg (it's been quite a while since I flew commercially) and a SDXC card that can store 200 GB weighs 5 grams (seems a reasonable back-of-the-napkin estimate), that would allow approximately 200 GB * 2,000 = 400 TB transferred in say ten hours flight time, for a 40 TB/h ~ 11 GB/s (90 Gb/s) throughput, disregarding the time to write to and read from the media (which applies equally with a stationwagon or FedEx). If the ticket costs $500, that's roughly 200 Mb/s per dollar (and remember, we are only relying on carry-on here). What's more, it is relatively trivially parallelizable at an approximately linear increase in cost, and can be scaled according to need at each time. If you can live with the risk of rough handling, the throughput per dollar approximately quadruples (700-900 Mb/s/$) given a 20 kg per person maximum checked-in baggage weight. 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) ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] Unix v6 problem with /tmp 2016-07-27 21:10 ` William Pechter 2016-07-28 0:49 ` Clem cole @ 2016-07-28 1:03 ` Clem cole 1 sibling, 0 replies; 22+ messages in thread From: Clem cole @ 2016-07-28 1:03 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1066 bytes --] Bill - below 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: > > 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... I had to laugh. A few months back I was working with a very bright 20 something engineers (from one of my alma mater's ) who is working on our new Xpoint memory technology. I had to explain to him some of these new behaviors / inventions were how things like core memory worked as well as showing him some info on the ML11 with exactly these type of features. He had no idea. While I'm not part of the the Xpoint team I have no idea what will end up as exposed features in final product or how people configure them but it's interesting to watch some ideas that stopping being fashionable or maybe economical be (re)discovered. What is new is old and old is now new😎 Clem ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] environments/universes (was: Unix v6 problem with /tmp) 2016-07-27 20:57 ` Clem Cole 2016-07-27 21:01 ` Clem Cole 2016-07-27 21:10 ` William Pechter @ 2016-07-28 23:16 ` Sven Mascheck 2016-07-29 3:05 ` arnold 2016-07-29 13:55 ` Clem Cole 2 siblings, 2 replies; 22+ messages in thread From: Sven Mascheck @ 2016-07-28 23:16 UTC (permalink / raw) On Wed, Jul 27, 2016 at 04:57:47PM -0400, Clem Cole wrote: > 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. How did you implement it? > 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. I just wonder if and how the following are related to the above two. Sequent Dynix "universes" (idea picked up by Siemens Sinix) puts several targets in one symlink. Example: ln -c ucb=.bin att=/usr/att/bin /bin and the actual resolving (and usage of different default PATHs) is controlled by an environment variable, as far as I know (s.a. http://www.in-ulm.de/~mascheck/various/universes/) HP-UX 9 "context dependent files" (as early alternative to NFS) make use of the set uid bit on directories and work like this, # mkdir /etc/inittab # chmod +H /etc/inittab # touch /etc/inittab+/node1 /etc/inittab+/default By accessing /etc/inittab, node1 will see the file node1, other systems will see default (s.a. http://www.in-ulm.de/~mascheck/various/permissions/) > [...] > You are right the BSD 4.2 made the world know about them but like > a number of things in BSD (such as networking) it was in some > cases a (better) integration of ideas others had played with before. F.i. #! also got widely known in 4.2BSD but was suggested by DMR before 8th ed. -Sven ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] environments/universes (was: Unix v6 problem with /tmp) 2016-07-28 23:16 ` [TUHS] environments/universes (was: Unix v6 problem with /tmp) Sven Mascheck @ 2016-07-29 3:05 ` arnold 2016-07-29 14:14 ` Clem Cole 2016-07-29 13:55 ` Clem Cole 1 sibling, 1 reply; 22+ messages in thread From: arnold @ 2016-07-29 3:05 UTC (permalink / raw) Sven Mascheck <mascheck at in-ulm.de> wrote: > Sequent Dynix "universes" (idea picked up by Siemens Sinix) puts several > targets in one symlink. Example: > > ln -c ucb=.bin att=/usr/att/bin /bin > > and the actual resolving (and usage of different default PATHs) > is controlled by an environment variable, as far as I know > (s.a. http://www.in-ulm.de/~mascheck/various/universes/) Pyramid did something similar, also called universes, in the mid-80s. I think they used a system call and corresponding command to set the visible universe either to BSD or System V. I don't remember the details as to how exactly it worked. I *think* this was before Dynix, but I'm not sure. We had a Pyramid when I was working at Georgia Tech. DMR visited one time and spoke; I remember him saying that he thought what Pyramid had done was an awful idea... :-) (They were interesting machines. It was RISC, with loadable microcode... About the same speed as a Vax 780 but half the price.) Arnold ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] environments/universes (was: Unix v6 problem with /tmp) 2016-07-29 3:05 ` arnold @ 2016-07-29 14:14 ` Clem Cole 0 siblings, 0 replies; 22+ messages in thread From: Clem Cole @ 2016-07-29 14:14 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2345 bytes --] On Thu, Jul 28, 2016 at 11:05 PM, <arnold at skeeve.com> wrote: > DMR visited one time > and spoke; I remember him saying that he thought what Pyramid had done > was an awful idea... :-) > He was right technically/theoretically, but wrong in practice for economic reasons. Yes, I remember talking to him about the idea at dinner at a USENIX. And I understood and agree the crude and somewhat confusing nature of the solution. T he basic argument behind them was practicality of porting code from the different flavors (much less being "finger ROM" compatible for users like me) . At this time System III/V and BSD were very much on divergent paths. Larger firms like DEC and HP-UX took a stand being either BSD or System V flavored (Sun started one way, sold there soul, then started to add all the BSD stuff back into SVR4). AT&T was making such a ruckus about "Consider it Standard" - but remember dmr never used ISV code, he wrote his own. So the problem was that s maller firms like Masscomp, P yra mid , Sequent did not have the leverage that HP, IBM or DEC thought they had with the ISVs (they did originally but time would change as Alpha/Tru64 proved). Being technically correct was not "good enough" - being economically for the ISVs and End users was important. Universes brought the price of porting code way down, because it allowed the AT&T "standard" or sort of be true, but still allowing a smaller firm to how their own extensions/differentiation and provide the "comforts" of BSD. In the end, it did not matter to the ISVs and why the UNIX "systems" vendors eventually failed. It was all about volume and the left UNIX for Winders when that that system could support their codes and became more economical. I remember having the conversation with one of the DEC EVPs explaining why even the Digitial Equipment Corp could not keep the ISVs on Alpha/Tru64. Being only technically correct/great was not a recipe for financial success of a firm. Anyway, he's not here to defend his technical position, but I do think dmr understood why it was the way it was. As you said, he did not like it. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160729/b017dc70/attachment.html> ^ permalink raw reply [flat|nested] 22+ messages in thread
* [TUHS] environments/universes (was: Unix v6 problem with /tmp) 2016-07-28 23:16 ` [TUHS] environments/universes (was: Unix v6 problem with /tmp) Sven Mascheck 2016-07-29 3:05 ` arnold @ 2016-07-29 13:55 ` Clem Cole 1 sibling, 0 replies; 22+ messages in thread From: Clem Cole @ 2016-07-29 13:55 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2846 bytes --] below On Thu, Jul 28, 2016 at 7:16 PM, Sven Mascheck <mascheck at in-ulm.de> wrote: > On Wed, Jul 27, 2016 at 04:57:47PM -0400, Clem Cole wrote: > > 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. > > How did you implement it? > Details are little fuzzy on some of the corner cases. If I thought about it, I bet they all come back. But basically bit crumbs in the u_area containing the "context" and then only trick was parsing the string in nami/lookup, so you could have N actions depending on the value of the context. i.e. path with embedded context string and grabbed another special character (which if I recall we used the @ to deliminate followed by a null then context1-> replacement1<null>context2->replacement2<null> .... contextN->nth replacement<null> which was originally linearly searched since the original use (universes) had a small number of contexts. When realized how useful they were @ LCC, and started to add support for clusters and the node name became one of the contexts, we had to get a bit smarter. Tru64 and the unreleased HP-UX implementation did some hashing and cleanup. I've forgotten if that was done before or after the Intel Paragon implementation. BSD symlink semantics was then left alone, although I think I remember I hacked the set/read code to handle the special char -- again IIR for set to translate foo at bar to be foo@@bar and read the opposite. Obviously you have a new failure of of the context did not match and an open question of how to set/get the different contexts which varied. For universes (which like Pyramid and others, Masscomp RTU also provided ), my recollection was a new command hacked into the shells and we had a general set/get variable services that predates the system variable stuff of the BSDs and later Unix (that was modeled on VMS given the Masscomp folks were sometimes ex-VMS kernel developers). For the original work at LCC (which is what went into HP-UX and the Paragon IIRC) , we had a new system service for contexts and I've forgotten how that worked; but it was different from the Masscomp or later BSD style scheme . As for m y memory of Tru64 (which only used CDSL's for handling node dependant info); the node name was set independently using yet another scheme (which I've now forgotten), but was already in the u_area so we could just look aside. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160729/cfa7cab0/attachment.html> ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2016-08-01 11:36 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-07-27 20:28 [TUHS] Unix v6 problem with /tmp Mark Longridge 2016-07-27 20:31 ` William Pechter 2016-07-27 20:57 ` Clem Cole 2016-07-27 21:01 ` Clem Cole 2016-07-27 21:10 ` William Pechter 2016-07-28 0:49 ` Clem cole 2016-07-28 1:03 ` William Pechter 2016-07-28 11:23 ` [TUHS] History repeating itself (was: Unix v6 problem with /tmp) Michael Kjörling 2016-07-28 12:18 ` Tony Finch 2016-07-28 13:57 ` John Cowan 2016-07-30 7:56 ` Greg 'groggy' Lehey 2016-07-30 11:41 ` William Cheswick 2016-07-30 23:28 ` Greg 'groggy' Lehey 2016-07-30 23:50 ` scj 2016-08-01 11:36 ` Tony Finch 2016-07-30 14:15 ` John Cowan 2016-07-30 15:30 ` [TUHS] History repeating itself Michael Kjörling 2016-07-28 1:03 ` [TUHS] Unix v6 problem with /tmp Clem cole 2016-07-28 23:16 ` [TUHS] environments/universes (was: Unix v6 problem with /tmp) Sven Mascheck 2016-07-29 3:05 ` arnold 2016-07-29 14:14 ` Clem Cole 2016-07-29 13:55 ` Clem Cole
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).