No collaborators. Not that I'm trying at all, the talk kinda got the urge out of my system. I therorize that many people could benefit - but no hard data. On Wed, Aug 13, 2025 at 6:41 PM Bakul Shah wrote: > I viewed this last October. Seemed like a bunch of sensible ideas. Did you > find any collaborators? [Not offering, just curious!] > > I see these "storage" categories: chunks, files, namespaces, metadata, > databases & streams [1]. If you define a network protocol to handle > critical operations on them all, implementations would likely follow. > Engineers do better with well defined boundaries compared to "somewhere > beyond there"! > > [1] probably could be simplified. > > On Aug 13, 2025, at 9:43 AM, Tom Lyon wrote: > > BTW, my own opinions abut NFS can be seen in my "NFS Must Die!" talk here: > https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon > > Not that NFS *was* bad - but it *is* bad (for non-casual use). > Like the C language, it was great for its time. Not so much anymore. > > > > On Wed, Aug 13, 2025 at 9:24 AM Peter Weinberger (温博格) via TUHS < > tuhs@tuhs.org> wrote: > >> It was a research proof-of-princple. (i.e.. partly principled and >> partly really hacky. My list of its issues was pretty long.) >> >> (If A mounted B's file system somewhere, and B mounted A's, then the >> directory tree was infinite. That's mathematics, not a bug.) >> >> On Wed, Aug 13, 2025 at 11:56 AM Larry McVoy wrote: >> > >> > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote: >> > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy >> > > wrote: >> > > > I was always sorry that Peter Weinberger's RFS never made it outside >> > > > Bell Labs. It allowed networking between separately administered >> > > > systems by mapping UIDs. >> > > >> > > I believe it did? If I recall correctly, it was available with System >> > > V, though perhaps I am misremembering. >> > >> > Sunos had it, my office mate ported it. I was unimpressed, it worked >> well >> > between the same archs but was riddled with byte order problems and >> > ioctl calls that were not portable. >> > >