site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com I wasn't aware I looking for anything. Did you mean responsiveness? I know who's working on it. It quite arguably is a filesystem. It's just not *a* filesystem but a hook for arbitrary filesystems. Dan, I had hoped that you would keep your pointless semantics arguments to the server lists. And what are you doing? Moreover since it affects the stability of the OS, and isn't anywhere ready for prime time nor is it likely to ever be ready for production, again in part b/c by nature it's a userspace "thingie", this would still be anathema. You do realise that, for example, webdavfs does all its HTTP communication from a userspace daemon? YMMV. -- -dhan ------------------------------------------------------------------------ Dan Shoop AIM: iWiring Systems & Networks Architect http://www.ustsvs.com/ shoop@iwiring.net http://www.iwiring.net/ 1-714-363-1174 "The wise man doesn't give the right answers, he poses the right questions." -- Claude Levi-Strauss ------------------------------------------------------------------------ iWiring provides systems and networks support for Mac OS X, unix, and Open Source application technologies at affordable rates. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... At 10:56 PM +0200 5/14/07, Uli Kusterer wrote: On 14.05.2007, at 18:56, Dan Shoop wrote: Moreover since it affects the stability of the OS, and isn't anywhere ready for prime time nor is it likely to ever be ready for production, again in part b/c by nature it's a userspace "thingie", this would still be anathema. Why would you assert that it'll never be ready for production "by nature"??? MacFUSE is a facility to move dangerous code out of the Kernel into user space, where it can't do as much damage. As we all know FUSE is a project to implement ad-hoc filesystems in user space. Ad-hoc filesystems are, by nature, not readily suitable for production. Hence my comment. Furthermore if the filesystem was production quality it would most likely be implemented within the system, not a user application. User based applications don't lend themselves well as production services. The fact that you even suggest that there could be dangerous code associated with such a ad-hoc filesystem further speaks to these issues. The potential for damage you mention here yourself is also unsuitable in a production environment. Realize that by "production" we necessarily referring to user workstations but production systems or application environments where you "bet your business" on your ability to perform the production operations required. If your concept of "production" is a user sitting at their MacBook at the cafe then you may find running experimental filesystems on an ad-hoc basis an acceptable risk, but in true production environments such risks from "dangerous code" that can cause "damage" is unacceptable. Making DAV under Darwin implemented in FUSE, as the OP suggested, would, in my opinion be a step backward in reliability, though it may be more elegant. I mean it's a nice thought, but given that it's supposed to be userspace, that the kernel and core OS are quite clearly kernel- and system-space, that it's not prime time ready, currently and probably always unstable by nature, and always going to be more appropriately implemented at a user level that it doesn't belong as part of the systems. FUSE *is* the User-Space-Kernel bridge you're looking for. Nonetheless I am familiar and do use FUSE in a few different OSen. This doesn't change my view, and informed opinion tempered by by almost 30 years of experience however. The actual file systems may be a different story, but MacFUSE really is something that should be a Kernel service. Well MacFuse requires a level of kernel support, but now you're asking for more than this it appears. It would even improve responsibility on the system. Just look what happens when you mount an FTP server in Finder, or a WebDAV server, and how it pretty much freezes the entire system's file I/O with the spinning beach ball because everyone is waiting for that FTP or DAV call to return, even those that just wanted to know what volumes are available. As for the issue you mention this would seem to be solvable by other means, and would be something I'd imagine the Darwin filesystem implementors already have on their radar[sic]. Don't get me wrong, MacFUSE is great, but it's experimental at best, at least currently. I agree it's pretty new, but flat-out stating it will never be ready for prime-time is arrogant, especially considering who the people working on this thing are, and that they're employed by one of the pickiest employers out there. I fail to see how it's arrogant to express either fact or an opinion, especially since the discussion was invited by the OP. It's a fact that FUSE creates ad-hoc fileystems. It's further clear that ad-hoc filesystems are anathema to production. This isn't changed by whomever works on the project. It's not demeaning to the FUSE developers to state facts nor is it arrogant as I'm not claiming any exaggerated sense of my own importance by making any of these statements. At 12:31 AM +0100 5/15/07, Finlay Dobbie wrote: On 14/05/07, Dan Shoop <shoop@iwiring.net> wrote: You're confusing "filesystem" with "VFS plug-in", but that's hardly surprising. Again Finlay your attempts to read my mind have failed as I have no such confusion, thank-you. You might do better to stay on topic than engage in ad hominem discussions. Yes, I do. I also realize that the code for this filesystem is part of the system, not some third party or ad hoc endeavor. FUSE filesystems are not system code but user code implemented on an ad hoc basis and as such -- it's my opinion -- are not suitable or ready for inclusion in the system at this time. This email sent to site_archiver@lists.apple.com