From dnm@pobox.com Wed Jul 11 17:33:38 2001 From: dnm@pobox.com (Dan Moniz) Date: Wed, 11 Jul 2001 12:33:38 -0400 Subject: OpenCol Swarmcast Message-ID: Hi Ted, I just came across your web page about the bluesky mailing list and noticed OpenCola Swarmcast mentioned. One correction: Swarmcast isn't commercial, it's open source . Bias disclosure: (my work .sig tells all...) -- Dan Moniz [http://www.opencola.com/] Research Scientist and Chief Security Architect OpenCola, 160 Bloor St E Suite 160, Toronto ON M4W 1B9, Canada V: +1 416 934 5520 | F: +1 416 966 9596 | M: +1 416 896 3266 Thanks! -- Dan Moniz [http://www.pobox.com/~dnm/] From dnm@pobox.com Wed Jul 11 19:38:24 2001 From: dnm@pobox.com (Dan Moniz) Date: Wed, 11 Jul 2001 14:38:24 -0400 Subject: dLoo and BlueBox Message-ID: From the language-dev mailing list: >Date: Wed, 11 Jul 2001 10:16:48 -0600 >From: Nathan Torkington >To: perl6-language@perl.org >Cc: language-dev@netthink.co.uk >Subject: dLoo releases peer-to-peer programming language > > >From newsforge: > >nile writes, "Today, dLoo released the complete architecture of an >extensible peer-to-peer programming language. Unlike traditional languages, >this language is defined on the Internet. Its syntax and semantics can be >extended by posting additional pieces of the language. As developers add to >the language it scales in richness and functionality. Programs run in a >software browser called BlueBox which dynamically downloads and assembles >the parts of the language as needed. For more information and access to the >source visit http://www.dloo.org. BlueBox is a community driven project >released under the GPL." >http://www.dloo.org/ -- Dan Moniz [http://www.pobox.com/~dnm/] From josh@mercuryfs.net Mon Jul 30 01:54:44 2001 From: josh@mercuryfs.net (Josh) Date: Sun, 29 Jul 2001 20:54:44 -0400 Subject: i've got a design you guys would be interested in Hello, I've designed a permanent caching location independent global file system. As such, it appears to be the only design to solve the duplication problem, which is inherent with Internet traffic. I'm just now starting to read thru the past emails, and look forward to speaking with some of you. As techies, I recommend you go straight to the presentation, which shows the essence of permanent caching and location independence. Its at www.mercuryfs.net/presentations/intro_to_mfs.htm - josh www.mercuryfs.net From wesley@felter.org Sun Jul 29 21:45:47 2001 From: wesley@felter.org (Wesley Felter) Date: Sun, 29 Jul 2001 15:45:47 -0500 (CDT) Subject: i've got a design you guys would be interested in In-Reply-To: Message-ID: On Sun, 29 Jul 2001, Josh wrote: > Hello, I've designed a permanent caching location independent global file > system. As such, it appears to be the only design to solve the duplication > problem, which is inherent with Internet traffic. How is your system different from OceanStore? > As techies, I recommend you go straight to the presentation, which shows > the essence of permanent caching and location independence. Its at > www.mercuryfs.net/presentations/intro_to_mfs.htm This appears to be in a weird format, so I couldn't view it. Wesley Felter - wesley@felter.org - http://felter.org/wesley/ From josh@mercuryfs.net Mon Jul 30 05:49:49 2001 From: josh@mercuryfs.net (Josh) Date: Sun, 29 Jul 2001 21:49:49 -0700 Subject: i've got a design you guys would be interested in In-Reply-To: Message-ID: <000001c118b3$110753b0$0100007f@koi> To be honest, I've never heard of ocean store. Thanks, I will look it up immediately. I found out about freenet via an attorney. I've been so focused on the design that I haven't read up on all the others... yet.. As for the presentation, you probably need the shockwave player, the flash player won't do it. The link to it is at my site, www.mercuryfs.net/presentations. - josh -----Original Message----- From: Wesley Felter [mailto:wesley@felter.org] Sent: Sunday, July 29, 2001 1:46 PM To: Global-Scale Distributed Storage Systems Subject: Re: i've got a design you guys would be interested in On Sun, 29 Jul 2001, Josh wrote: > Hello, I've designed a permanent caching location independent global file > system. As such, it appears to be the only design to solve the duplication > problem, which is inherent with Internet traffic. How is your system different from OceanStore? > As techies, I recommend you go straight to the presentation, which shows > the essence of permanent caching and location independence. Its at > www.mercuryfs.net/presentations/intro_to_mfs.htm This appears to be in a weird format, so I couldn't view it. Wesley Felter - wesley@felter.org - http://felter.org/wesley/ --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From agl@linuxpower.org Mon Jul 30 20:41:43 2001 From: agl@linuxpower.org (Adam Langley) Date: Mon, 30 Jul 2001 12:41:43 -0700 Subject: i've got a design you guys would be interested in In-Reply-To: ; from josh@mercuryfs.net on Sun, Jul 29, 2001 at 08:54:44PM -0400 References: Message-ID: <20010730124143.B29480@linuxpower.org> On Sun, Jul 29, 2001 at 08:54:44PM -0400, Josh wrote: > Hello, I've designed a permanent caching location independent global file > system. As such, it appears to be the only design to solve the duplication > problem, which is inherent with Internet traffic. Warning people - this guy has been trolling the Freenet lists. AGL From bram@gawth.com Tue Jul 31 02:42:56 2001 From: bram@gawth.com (Bram Cohen) Date: Mon, 30 Jul 2001 18:42:56 -0700 (PDT) Subject: i've got a design you guys would be interested in In-Reply-To: Message-ID: On Sun, 29 Jul 2001, Josh wrote: > To be honest, I've never heard of ocean store. Thanks, I will look it up > immediately. I found out about freenet via an attorney. I've been so focused > on the design that I haven't read up on all the others... yet.. As for the > presentation, you probably need the shockwave player, the flash player won't > do it. The link to it is at my site, www.mercuryfs.net/presentations. I poked around your site, and get the impression you're spinning your main advantage is downloading content from the local network, thus saving costs for the ISP. Others have this idea as well, but I think it's going after the wrong market. The customer of a p2p application is the end user. End users really, really don't care about costs to their ISP. They might care a bit about latency, although that's already toast for napster, gnutella, freenet, bittorrent, and just about everything else. They also might care about download time, but the bottleneck is going to be the bandwidth of their net connection. There are exceptions to this, such as students at very large universities and people in very large companies, who have much faster connections to each other than the net at large, but generally speaking, the main performance problems of p2p are finding someone else you want, getting them to offer it for upload, and using your whole net connection. I've basically chucked working on anything but those three problems for BitTorrent, and even that's proving to require quite the technical tour de force to get right. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From josh@mercuryfs.net Tue Jul 31 02:45:33 2001 From: josh@mercuryfs.net (Josh) Date: Mon, 30 Jul 2001 18:45:33 -0700 Subject: freeent In-Reply-To: Message-ID: <000e01c11962$7d9b1750$35512304@koi> HA HA HA!!!! Trolling means I'm trying to get them into my nets? Nooooo... I'm hiring this thing built, by pro's like VA linux. Their committee will take forever. Besides, the freenet community seems to hide behind the 1st amendment too much, and I just don't agree with that philosophy. I respect patents and intellectual property. Besides, any computer hack with half a brain can bypass any copy protection scheme. Luckily, this email list says to keep philosophy and law out of it, so this will be my last submission on that topic. (smiling, like howard stearn) -----Original Message----- From: agl@hawk.freenetproject.org [mailto:agl@hawk.freenetproject.org] On Behalf Of Adam Langley Sent: Monday, July 30, 2001 12:42 PM To: Global-Scale Distributed Storage Systems Subject: Re: i've got a design you guys would be interested in On Sun, Jul 29, 2001 at 08:54:44PM -0400, Josh wrote: > Hello, I've designed a permanent caching location independent global file > system. As such, it appears to be the only design to solve the duplication > problem, which is inherent with Internet traffic. Warning people - this guy has been trolling the Freenet lists. AGL --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From josh@mercuryfs.net Tue Jul 31 03:12:16 2001 From: josh@mercuryfs.net (Josh) Date: Mon, 30 Jul 2001 19:12:16 -0700 Subject: the mercury file system In-Reply-To: Message-ID: <000f01c11966$38d50e10$35512304@koi> True! However, I hope to entice the home users because of the other features, such as security and async mirroring (what will make The Internet as Primary Disk scenario a reality). In the beginning, ISPs, universities, and large corporations will be the first. My thoughts are to get it deployed at the ISPs first (make their features into ver 1.0), because of the cost savings to them. MFS has a major advantage over all the existing caching methods (that I know of). Here's a link to an email that touches on that subject. http://www.mercuryfs.net/essence3.htm My goal is to make true telecommuting possible. If I can keep it together as a single standard, and obsolete NFS, it can happen. With MFS, if you were to map a drive letter to the office, via a modem, and run Microsoft office off of your server at work, it will be slow the first time only. The permanent caching feature makes a lot of other features possible. It also has a lot of promise for fault tolerance. My ultimate goal is The Anywhere PC scenario. I'm convinced there will be enough demand for that type of functionality, that the rest of the system will be adopted. I want anybody to be able to use almost any PC to access the same desktop. The only variable is speed. This cant be accomplished just a file system, but it's the main challenge that I see. I figure Java can do the rest. The main difference with MFS is that it accesses a file by its data, using a formula that can be extracted from the data and URL. By doing it this way, the provider is irrelevant. Security, the MFS hierarchy, and time do not apply to this method. The p2p performance kicks in because anybody can provide that file (via MFS handle). When you login, you upload your 10,000 most recently accessed MFS handles to "My Group" which is either your LAN or your ISP. In the background it continues to update the inventory of what you have downloaded since logging in. This way, the entire group can benefit from your file accesses, thus keeping traffic local to My Group. Because MFS handles do not indicate what the file is, there is a level of privacy here. I've also figured out a method to trust your neighbors, while keeping their identity nearly anonymous. That way, should your trust list be obtained, its next to useless. With the privacy issue and technical issues dealt with, I think it will really dominate in p2p environments. MFS is a hybrid between client/sever and peer to peer. It has the advantages of both. It utilizes storage far more efficiently than client/server, yet retains its centralness that should allow it to scale in a linear fashion. It's got the performance of peer to peer because the servers are not the bottleneck, unlike client/server. With location independence, if a server is busy it will forward the request to another server/client that's not. It's designed to run on anything. From a technical perspective, I see no reason why it can't emulate all the others. (at least not yet) - josh -----Original Message----- From: Bram Cohen [mailto:bram@gawth.com] Sent: Monday, July 30, 2001 6:43 PM To: Global-Scale Distributed Storage Systems Subject: RE: i've got a design you guys would be interested in On Sun, 29 Jul 2001, Josh wrote: > To be honest, I've never heard of ocean store. Thanks, I will look it up > immediately. I found out about freenet via an attorney. I've been so focused > on the design that I haven't read up on all the others... yet.. As for the > presentation, you probably need the shockwave player, the flash player won't > do it. The link to it is at my site, www.mercuryfs.net/presentations. I poked around your site, and get the impression you're spinning your main advantage is downloading content from the local network, thus saving costs for the ISP. Others have this idea as well, but I think it's going after the wrong market. The customer of a p2p application is the end user. End users really, really don't care about costs to their ISP. They might care a bit about latency, although that's already toast for napster, gnutella, freenet, bittorrent, and just about everything else. They also might care about download time, but the bottleneck is going to be the bandwidth of their net connection. There are exceptions to this, such as students at very large universities and people in very large companies, who have much faster connections to each other than the net at large, but generally speaking, the main performance problems of p2p are finding someone else you want, getting them to offer it for upload, and using your whole net connection. I've basically chucked working on anything but those three problems for BitTorrent, and even that's proving to require quite the technical tour de force to get right. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From bram@gawth.com Tue Jul 31 03:25:43 2001 From: bram@gawth.com (Bram Cohen) Date: Mon, 30 Jul 2001 19:25:43 -0700 (PDT) Subject: the mercury file system In-Reply-To: Message-ID: On Mon, 30 Jul 2001, Josh wrote: > True! However, I hope to entice the home users because of the other > features, such as security and async mirroring (what will make The Internet > as Primary Disk scenario a reality). While it's natural to try and make your project do as much as it possibly can, the failure rate of software projects is such that I for one try and make mine do just one thing for one person. A successful project which does very little is, after all, more useful than a failed one which tried to do a lot. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From josh@mercuryfs.net Tue Jul 31 03:25:26 2001 From: josh@mercuryfs.net (Josh) Date: Mon, 30 Jul 2001 19:25:26 -0700 Subject: the mercury file system In-Reply-To: Message-ID: <001001c11968$0fb4e0d0$35512304@koi> This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C1192D.635608D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Yes, but you gotta see the engineering details. This really is a very basic design, as far as global file systems go. I actually won a bet by keeping it within a 2 inch binder (its still incomplete). I agree, everybody else out there has problems with this type of project. I have studied the political challenges more than the engineering challenges, to be honest. I figured that even if I get the design to work, I would never be allowed to distribute it. The only way MFS will be successful is if the world trusts it, so it has to have strong encryption. I've put together a basic plan for the revisions, its attached. Basically, I intend to get it up and running as a read only file sharing program, then read write, then move it into the kernel. I've gotta have reliability as #1. That's why I'm going for funding. Even if we did code it, we don't have the support infrastructure that the initial versions will require, before Microsoft and novell take over and write their own clients. If it gets to that point. By starting off as a database, I can borrow all their clustering, fault tolerance, mirroring, load balancing, etc etc. I intend to keep it as a dbase project until versions 2 or 3. -----Original Message----- From: Bram Cohen [mailto:bram@gawth.com] Sent: Monday, July 30, 2001 7:26 PM To: Global-Scale Distributed Storage Systems Cc: Steven Torres (E-mail); Lana Akamine (E-mail); Charles (E-mail) Subject: Re: the mercury file system On Mon, 30 Jul 2001, Josh wrote: > True! However, I hope to entice the home users because of the other > features, such as security and async mirroring (what will make The Internet > as Primary Disk scenario a reality). While it's natural to try and make your project do as much as it possibly can, the failure rate of software projects is such that I for one try and make mine do just one thing for one person. A successful project which does very little is, after all, more useful than a failed one which tried to do a lot. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ ------=_NextPart_000_0011_01C1192D.635608D0 Content-Type: text/plain; name="mfs versions.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mfs versions.txt" 0.1 Single OS, file sharing utility (outside kernel), read only, no = encryption, no mfs domains, no friendship protocol, no default = replication, no http/html. 0.2 focus on S2 and S3 design, begin designing load test apps 0.3 focus on S1 design but stil read only, my group dbase, processes (1601) 0.4 dns load balancing, mfs domains, begin building S0 network=09 0.5 manual sync groups, lay groundwork for auto sync groups, default record = replication, begin building UNI ID 0.6 encryption 0.7 multiple S1s (multi location), lay groundwork for read/write mode 0.8 timestamping, NTP, virtual servers, processes (1604, 1607)=20 0.9 read/write mode, processes (1602, 1603, 1604, 1605), virtual servers 1.0 auto sync groups, begin linux kernel driver development 1.1 =09 Virtual CDs 1.2 =09 async mirroring 1.5=20 SE linux kernel mode version, begin NT driver development,=20 ------=_NextPart_000_0011_01C1192D.635608D0-- From bram@gawth.com Tue Jul 31 04:00:40 2001 From: bram@gawth.com (Bram Cohen) Date: Mon, 30 Jul 2001 20:00:40 -0700 (PDT) Subject: the mercury file system In-Reply-To: Message-ID: On Mon, 30 Jul 2001, Josh wrote: > Yes, but you gotta see the engineering details. This really is a very basic > design, as far as global file systems go. I actually won a bet by keeping it > within a 2 inch binder (its still incomplete). Any design which requires a 2" binder to hold it is completely out of control. > I have studied the political challenges more than the engineering > challenges, to be honest. I figured that even if I get the design to > work, I would never be allowed to distribute it. The only way MFS will > be successful is if the world trusts it, so it has to have strong > encryption. I predict you'll never get to the point of having such problems, for purely technical reasons. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From josh@mercuryfs.net Tue Jul 31 04:09:55 2001 From: josh@mercuryfs.net (Josh) Date: Mon, 30 Jul 2001 20:09:55 -0700 Subject: the mercury file system In-Reply-To: Message-ID: <000101c1196e$46e1baa0$35512304@koi> Bet me $100? And read the design. -----Original Message----- From: Bram Cohen [mailto:bram@gawth.com] Sent: Monday, July 30, 2001 8:01 PM To: Global-Scale Distributed Storage Systems Cc: Charles (E-mail); Steven Torres (E-mail); Lana Akamine (E-mail) Subject: RE: the mercury file system On Mon, 30 Jul 2001, Josh wrote: > Yes, but you gotta see the engineering details. This really is a very basic > design, as far as global file systems go. I actually won a bet by keeping it > within a 2 inch binder (its still incomplete). Any design which requires a 2" binder to hold it is completely out of control. > I have studied the political challenges more than the engineering > challenges, to be honest. I figured that even if I get the design to > work, I would never be allowed to distribute it. The only way MFS will > be successful is if the world trusts it, so it has to have strong > encryption. I predict you'll never get to the point of having such problems, for purely technical reasons. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From bram@gawth.com Tue Jul 31 04:24:09 2001 From: bram@gawth.com (Bram Cohen) Date: Mon, 30 Jul 2001 20:24:09 -0700 (PDT) Subject: the mercury file system In-Reply-To: Message-ID: On Mon, 30 Jul 2001, Josh wrote: > Bet me $100? And read the design. Your bluster is comical. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From josh@mercuryfs.net Tue Jul 31 04:19:51 2001 From: josh@mercuryfs.net (Josh) Date: Mon, 30 Jul 2001 20:19:51 -0700 Subject: NT & UNIX integration Message-ID: <000201c1196f$a9b32a00$35512304@koi> Anybody know of a way to get NT's structured exception handling to work in unix? Any kits out there? I'm aiming for 1 codebase, but I think it's a fantasy. From josh@mercuryfs.net Tue Jul 31 04:23:22 2001 From: josh@mercuryfs.net (Josh) Date: Mon, 30 Jul 2001 20:23:22 -0700 Subject: the mercury file system In-Reply-To: Message-ID: <000301c11970$27bc7be0$35512304@koi> Why? I won $500, so I can afford to loose 5 of these bets! besides, I've been thinking about this for 10 years. There's a 10 page summary, you can probably read it quickly. I figure, even if it fails, the trademarks are cool. :) -----Original Message----- From: Bram Cohen [mailto:bram@gawth.com] Sent: Monday, July 30, 2001 8:24 PM To: Global-Scale Distributed Storage Systems Cc: 'Charles (E-mail)'; 'Steven Torres (E-mail)'; 'Lana Akamine (E-mail)' Subject: RE: the mercury file system On Mon, 30 Jul 2001, Josh wrote: > Bet me $100? And read the design. Your bluster is comical. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From dnm@pobox.com Tue Jul 31 04:49:19 2001 From: dnm@pobox.com (Dan Moniz) Date: Mon, 30 Jul 2001 23:49:19 -0400 Subject: the mercury file system In-Reply-To: References: Message-ID: I've avoided posting on this thread here because I was waiting for Bram to get to it. Hi Bram! >True! However, I hope to entice the home users because of the other >features, such as security and async mirroring (what will make The Internet >as Primary Disk scenario a reality). In the beginning, ISPs, universities, >and large corporations will be the first. My thoughts are to get it deployed >at the ISPs first (make their features into ver 1.0), because of the cost >savings to them. MFS has a major advantage over all the existing caching >methods (that I know of). Here's a link to an email that touches on that >subject. http://www.mercuryfs.net/essence3.htm > >My goal is to make true telecommuting possible. If I can keep it together as >a single standard, and obsolete NFS, it can happen. With MFS, if you were to >map a drive letter to the office, via a modem, and run Microsoft office off >of your server at work, it will be slow the first time only. The permanent >caching feature makes a lot of other features possible. It also has a lot of >promise for fault tolerance. I don't mean to rain on anyone's parade here, and please excuse me for thinking like an engineer in the next few points: Assuming I bought all the rhetoric, which seems vapid and more like a press release than a technical clarification, what makes you different, at least in the abstract, from SFS , or like Wesley asked, OceanStore ? I'd like to see some point by point technical comparisons. It ought to be easy with OceanStore because you wouldn't have to pony up any code, just design points that explicitly show the differences. I could get into all I see wrong with the string of comments starting with "With MFS if you were to map a drive letter to the office, via a modem, [...] it will be slow the first time only [...] makes a lot of other features possible [...].", but I don't really think I need to. >My ultimate goal is The Anywhere PC scenario. I'm convinced there will be >enough demand for that type of functionality, that the rest of the system >will be adopted. I want anybody to be able to use almost any PC to access >the same desktop. The only variable is speed. This cant be accomplished just >a file system, but it's the main challenge that I see. I figure Java can do >the rest. Huh? What? Come again? You see speed as being the main barrier to a global filesystem that people access over the Internet (or a modem as well, if I'm interpreting the text above correctly)? You think the system will be adopted due to some fictional amount of functionality, itself something I would generously call "confused"? And you think that Java can handle "the rest"? Maybe I'm the bigger idiot for biting the bait being trolled past me, but in honestly, I'd really like to find out what the hell is going on . I don't see anything worth looking at here, and I'm not convinced you've done any amount of homework. >The main difference with MFS is that it accesses a file by its data, using a >formula that can be extracted from the data and URL. By doing it this way, "It accesses a file by it's data, using a formula that can be extracted from the data and URL"? How do other filesystems access files in comparison to MFS? Furthermore (see below).... >the provider is irrelevant. Security, the MFS hierarchy, and time do not How does this revolutionary method make the provide irrelevant? Wasn't I just using a modem to run Microsoft Office off of a server and then magically getting some other amazing speed benefits? What's this talk of providers? >apply to this method. The p2p performance kicks in because anybody can >provide that file (via MFS handle). When you login, you upload your 10,000 >most recently accessed MFS handles to "My Group" which is either your LAN or >your ISP. In the background it continues to update the inventory of what you >have downloaded since logging in. This way, the entire group can benefit >from your file accesses, thus keeping traffic local to My Group. Because MFS >handles do not indicate what the file is, there is a level of privacy here. Where? If I somehow use a formula that's extracted from the data and the URL to access a file by it's data (huh?), where would MFS handles matter? Furthermore, what exactly is the pseudoscientific premise behind all of this? I hope you understand that this sounds like a lot of crap. Seriously. I keep hoping there's a real idea here, but so far, everything seems disjointed, with no real detail, with no outward indication that you've studied any of the other systems you claim to be better than. >I've also figured out a method to trust your neighbors, while keeping their >identity nearly anonymous. That way, should your trust list be obtained, its >next to useless. With the privacy issue and technical issues dealt with, I >think it will really dominate in p2p environments. MFS is a hybrid between >client/sever and peer to peer. It has the advantages of both. It utilizes >storage far more efficiently than client/server, yet retains its centralness >that should allow it to scale in a linear fashion. It's got the performance Hybrid systems are something I have significant experience with. Please do explain, in detail, how you maintain linear scalability of resources in your hybrid model. I'd like to see some math backing your story before I buy this. >of peer to peer because the servers are not the bottleneck, unlike >client/server. With location independence, if a server is busy it will But a server would have to be a bottleneck if it's a hybrid system. It may not be a critical bottleneck, but again, at this point, I think I'm constructing in my head way more than you have actually thought out and had validated by people who know what they're doing. >forward the request to another server/client that's not. It's designed to >run on anything. From a technical perspective, I see no reason why it can't >emulate all the others. (at least not yet) Run on anything how? Java? How does this solve the issues of presenting me with a native Windows file share, like you mention way at the top (y'know, over a modem line, et alia)? Wow. This is obtuse. It can emulate all the other what? Filesystems? P2P systems? Databases? Bass-o-Matics? I'm still hungry for real meat. -- Dan Moniz [http://www.pobox.com/~dnm/] From josh@mercuryfs.net Tue Jul 31 04:55:15 2001 From: josh@mercuryfs.net (Josh) Date: Mon, 30 Jul 2001 20:55:15 -0700 Subject: the mercury file system In-Reply-To: Message-ID: <000501c11974$9c2a1970$35512304@koi> Well.... The design is public. Perhaps you should read it, and respond in a technical way. -----Original Message----- From: Dan Moniz [mailto:dnm@pobox.com] Sent: Monday, July 30, 2001 8:49 PM To: Global-Scale Distributed Storage Systems Subject: Re: the mercury file system I've avoided posting on this thread here because I was waiting for Bram to get to it. Hi Bram! >True! However, I hope to entice the home users because of the other >features, such as security and async mirroring (what will make The Internet >as Primary Disk scenario a reality). In the beginning, ISPs, universities, >and large corporations will be the first. My thoughts are to get it deployed >at the ISPs first (make their features into ver 1.0), because of the cost >savings to them. MFS has a major advantage over all the existing caching >methods (that I know of). Here's a link to an email that touches on that >subject. http://www.mercuryfs.net/essence3.htm > >My goal is to make true telecommuting possible. If I can keep it together as >a single standard, and obsolete NFS, it can happen. With MFS, if you were to >map a drive letter to the office, via a modem, and run Microsoft office off >of your server at work, it will be slow the first time only. The permanent >caching feature makes a lot of other features possible. It also has a lot of >promise for fault tolerance. I don't mean to rain on anyone's parade here, and please excuse me for thinking like an engineer in the next few points: Assuming I bought all the rhetoric, which seems vapid and more like a press release than a technical clarification, what makes you different, at least in the abstract, from SFS , or like Wesley asked, OceanStore ? I'd like to see some point by point technical comparisons. It ought to be easy with OceanStore because you wouldn't have to pony up any code, just design points that explicitly show the differences. I could get into all I see wrong with the string of comments starting with "With MFS if you were to map a drive letter to the office, via a modem, [...] it will be slow the first time only [...] makes a lot of other features possible [...].", but I don't really think I need to. >My ultimate goal is The Anywhere PC scenario. I'm convinced there will be >enough demand for that type of functionality, that the rest of the system >will be adopted. I want anybody to be able to use almost any PC to access >the same desktop. The only variable is speed. This cant be accomplished just >a file system, but it's the main challenge that I see. I figure Java can do >the rest. Huh? What? Come again? You see speed as being the main barrier to a global filesystem that people access over the Internet (or a modem as well, if I'm interpreting the text above correctly)? You think the system will be adopted due to some fictional amount of functionality, itself something I would generously call "confused"? And you think that Java can handle "the rest"? Maybe I'm the bigger idiot for biting the bait being trolled past me, but in honestly, I'd really like to find out what the hell is going on . I don't see anything worth looking at here, and I'm not convinced you've done any amount of homework. >The main difference with MFS is that it accesses a file by its data, using a >formula that can be extracted from the data and URL. By doing it this way, "It accesses a file by it's data, using a formula that can be extracted from the data and URL"? How do other filesystems access files in comparison to MFS? Furthermore (see below).... >the provider is irrelevant. Security, the MFS hierarchy, and time do not How does this revolutionary method make the provide irrelevant? Wasn't I just using a modem to run Microsoft Office off of a server and then magically getting some other amazing speed benefits? What's this talk of providers? >apply to this method. The p2p performance kicks in because anybody can >provide that file (via MFS handle). When you login, you upload your 10,000 >most recently accessed MFS handles to "My Group" which is either your LAN or >your ISP. In the background it continues to update the inventory of what you >have downloaded since logging in. This way, the entire group can benefit >from your file accesses, thus keeping traffic local to My Group. Because MFS >handles do not indicate what the file is, there is a level of privacy here. Where? If I somehow use a formula that's extracted from the data and the URL to access a file by it's data (huh?), where would MFS handles matter? Furthermore, what exactly is the pseudoscientific premise behind all of this? I hope you understand that this sounds like a lot of crap. Seriously. I keep hoping there's a real idea here, but so far, everything seems disjointed, with no real detail, with no outward indication that you've studied any of the other systems you claim to be better than. >I've also figured out a method to trust your neighbors, while keeping their >identity nearly anonymous. That way, should your trust list be obtained, its >next to useless. With the privacy issue and technical issues dealt with, I >think it will really dominate in p2p environments. MFS is a hybrid between >client/sever and peer to peer. It has the advantages of both. It utilizes >storage far more efficiently than client/server, yet retains its centralness >that should allow it to scale in a linear fashion. It's got the performance Hybrid systems are something I have significant experience with. Please do explain, in detail, how you maintain linear scalability of resources in your hybrid model. I'd like to see some math backing your story before I buy this. >of peer to peer because the servers are not the bottleneck, unlike >client/server. With location independence, if a server is busy it will But a server would have to be a bottleneck if it's a hybrid system. It may not be a critical bottleneck, but again, at this point, I think I'm constructing in my head way more than you have actually thought out and had validated by people who know what they're doing. >forward the request to another server/client that's not. It's designed to >run on anything. From a technical perspective, I see no reason why it can't >emulate all the others. (at least not yet) Run on anything how? Java? How does this solve the issues of presenting me with a native Windows file share, like you mention way at the top (y'know, over a modem line, et alia)? Wow. This is obtuse. It can emulate all the other what? Filesystems? P2P systems? Databases? Bass-o-Matics? I'm still hungry for real meat. -- Dan Moniz [http://www.pobox.com/~dnm/] --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From josh@mercuryfs.net Tue Jul 31 04:56:04 2001 From: josh@mercuryfs.net (Josh) Date: Mon, 30 Jul 2001 20:56:04 -0700 Subject: the mercury file system In-Reply-To: Message-ID: <000601c11974$b8d3e600$35512304@koi> The point by point comparisons will be coming, as I read about the others. So far, ocean store looks very cool. What makes MFS unique is that it's the first design to separate a file into 2 fundamental units. -----Original Message----- From: Dan Moniz [mailto:dnm@pobox.com] Sent: Monday, July 30, 2001 8:49 PM To: Global-Scale Distributed Storage Systems Subject: Re: the mercury file system I've avoided posting on this thread here because I was waiting for Bram to get to it. Hi Bram! >True! However, I hope to entice the home users because of the other >features, such as security and async mirroring (what will make The Internet >as Primary Disk scenario a reality). In the beginning, ISPs, universities, >and large corporations will be the first. My thoughts are to get it deployed >at the ISPs first (make their features into ver 1.0), because of the cost >savings to them. MFS has a major advantage over all the existing caching >methods (that I know of). Here's a link to an email that touches on that >subject. http://www.mercuryfs.net/essence3.htm > >My goal is to make true telecommuting possible. If I can keep it together as >a single standard, and obsolete NFS, it can happen. With MFS, if you were to >map a drive letter to the office, via a modem, and run Microsoft office off >of your server at work, it will be slow the first time only. The permanent >caching feature makes a lot of other features possible. It also has a lot of >promise for fault tolerance. I don't mean to rain on anyone's parade here, and please excuse me for thinking like an engineer in the next few points: Assuming I bought all the rhetoric, which seems vapid and more like a press release than a technical clarification, what makes you different, at least in the abstract, from SFS , or like Wesley asked, OceanStore ? I'd like to see some point by point technical comparisons. It ought to be easy with OceanStore because you wouldn't have to pony up any code, just design points that explicitly show the differences. I could get into all I see wrong with the string of comments starting with "With MFS if you were to map a drive letter to the office, via a modem, [...] it will be slow the first time only [...] makes a lot of other features possible [...].", but I don't really think I need to. >My ultimate goal is The Anywhere PC scenario. I'm convinced there will be >enough demand for that type of functionality, that the rest of the system >will be adopted. I want anybody to be able to use almost any PC to access >the same desktop. The only variable is speed. This cant be accomplished just >a file system, but it's the main challenge that I see. I figure Java can do >the rest. Huh? What? Come again? You see speed as being the main barrier to a global filesystem that people access over the Internet (or a modem as well, if I'm interpreting the text above correctly)? You think the system will be adopted due to some fictional amount of functionality, itself something I would generously call "confused"? And you think that Java can handle "the rest"? Maybe I'm the bigger idiot for biting the bait being trolled past me, but in honestly, I'd really like to find out what the hell is going on . I don't see anything worth looking at here, and I'm not convinced you've done any amount of homework. >The main difference with MFS is that it accesses a file by its data, using a >formula that can be extracted from the data and URL. By doing it this way, "It accesses a file by it's data, using a formula that can be extracted from the data and URL"? How do other filesystems access files in comparison to MFS? Furthermore (see below).... >the provider is irrelevant. Security, the MFS hierarchy, and time do not How does this revolutionary method make the provide irrelevant? Wasn't I just using a modem to run Microsoft Office off of a server and then magically getting some other amazing speed benefits? What's this talk of providers? >apply to this method. The p2p performance kicks in because anybody can >provide that file (via MFS handle). When you login, you upload your 10,000 >most recently accessed MFS handles to "My Group" which is either your LAN or >your ISP. In the background it continues to update the inventory of what you >have downloaded since logging in. This way, the entire group can benefit >from your file accesses, thus keeping traffic local to My Group. Because MFS >handles do not indicate what the file is, there is a level of privacy here. Where? If I somehow use a formula that's extracted from the data and the URL to access a file by it's data (huh?), where would MFS handles matter? Furthermore, what exactly is the pseudoscientific premise behind all of this? I hope you understand that this sounds like a lot of crap. Seriously. I keep hoping there's a real idea here, but so far, everything seems disjointed, with no real detail, with no outward indication that you've studied any of the other systems you claim to be better than. >I've also figured out a method to trust your neighbors, while keeping their >identity nearly anonymous. That way, should your trust list be obtained, its >next to useless. With the privacy issue and technical issues dealt with, I >think it will really dominate in p2p environments. MFS is a hybrid between >client/sever and peer to peer. It has the advantages of both. It utilizes >storage far more efficiently than client/server, yet retains its centralness >that should allow it to scale in a linear fashion. It's got the performance Hybrid systems are something I have significant experience with. Please do explain, in detail, how you maintain linear scalability of resources in your hybrid model. I'd like to see some math backing your story before I buy this. >of peer to peer because the servers are not the bottleneck, unlike >client/server. With location independence, if a server is busy it will But a server would have to be a bottleneck if it's a hybrid system. It may not be a critical bottleneck, but again, at this point, I think I'm constructing in my head way more than you have actually thought out and had validated by people who know what they're doing. >forward the request to another server/client that's not. It's designed to >run on anything. From a technical perspective, I see no reason why it can't >emulate all the others. (at least not yet) Run on anything how? Java? How does this solve the issues of presenting me with a native Windows file share, like you mention way at the top (y'know, over a modem line, et alia)? Wow. This is obtuse. It can emulate all the other what? Filesystems? P2P systems? Databases? Bass-o-Matics? I'm still hungry for real meat. -- Dan Moniz [http://www.pobox.com/~dnm/] --- You are currently subscribed to bluesky as: josh@mercuryfs.net For list information visit http://www.transarc.ibm.com/~ota/bluesky/ From josh@mercuryfs.net Tue Jul 31 04:57:49 2001 From: josh@mercuryfs.net (Josh) Date: Mon, 30 Jul 2001 20:57:49 -0700 Subject: FW: attorneys Message-ID: <000701c11974$f76e5b70$35512304@koi> -----Original Message----- From: Josh [mailto:josh@mercuryfs.net] Sent: Monday, July 30, 2001 8:52 PM To: 'Bram Cohen' Subject: RE: attorneys Patent or not -----Original Message----- From: Josh [mailto:josh@mercuryfs.net] Sent: Monday, July 30, 2001 8:51 PM To: 'Bram Cohen' Subject: RE: attorneys You don't know microsofts history. They will take it from me. -----Original Message----- From: Bram Cohen [mailto:] Sent: Monday, July 30, 2001 8:52 PM To: Josh Subject: RE: attorneys On Mon, 30 Jul 2001, Josh wrote: > It's a free design, so long as its implemented in its entirety. Whatever. You've got a patent, you intend to use it, this can do nothing but cause trouble for other people. > Chill out, you cant judge somebody thu email. Ian refused to talk to me on > the phone after 1 email, because he prefers email. Its too limiting. I could be convinced otherwise, but thus far you sure seem like a twit. * Bram Cohen "Markets can remain irrational longer than you can remain solvent" * John Maynard Keynes From josh@mercuryfs.net Tue Jul 31 06:00:02 2001 From: josh@mercuryfs.net (Josh) Date: Mon, 30 Jul 2001 22:00:02 -0700 Subject: ocean store Message-ID: <000001c1197d$a895a3b0$35512304@koi> Based upon 15 minutes of reading, I don't see that ocean store separates the file like MFS does. Also, their model of a utility-like infrastructure is exactly what I'm aiming for. Where "the data is just out there". That's TRUE location independence. I intend for everybody to get the same features, only speed is the differentiation. Akamai's business model will be enhanced, because I intend to build in a for profit model and general use model into the quality of service / resource allocation algorithms, when they are built. That way everybody can use it, and if you want to ensure that your highly accessed files are replicated at the isp point of presences, there will be some type of feedback mechanism. I envision storage and bandwidth as commodities, when using MFS. So far, ocean store and MFS have more in common than any other technology, at least as far as our goals are concerned. I am anxious to hear back from the leader of the project, I also emailed one other member. I'm sure one of them ought to be a member of this group. I will get back with detailed comparisons, via my web site. I intend to be a good central location to jump to all similar projects. Aka I hope to build a good links page. So far this email group has been very useful, I will check out the SFS design in a while.