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(a)gmail.com> wrote:

Clem Cole wrote: 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/

Clem cole wrote: 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

Michael Kjörling <michael(a)kjorling.se> wrote: https://aws.amazon.com/importexport/disk/ :-) Tony. -- f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ - I xn--zr8h punycode South Fitzroy: Northerly 5 to 7. Moderate or rough. Fair. Good.

On Thursday, 28 July 2016 at 9:57:40 -0400, John Cowan wrote: 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(a)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

On Saturday, 30 July 2016 at 7:41:39 -0400, William Cheswick wrote: 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(a)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

William Cheswick <ches(a)cheswick.com> wrote: 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(a)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.

On 30 Jul 2016 10:15 -0400, from cowan(a)mercury.ccil.org (John Cowan): 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(a)kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup)

On Wed, Jul 27, 2016 at 04:57:47PM -0400, Clem Cole wrote: How did you implement it? 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/) F.i. #! also got widely known in 4.2BSD but was suggested by DMR before 8th ed. -Sven

On Thu, Jul 28, 2016 at 11:05 PM, <arnold(a)skeeve.com> wrote: ​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