May 2007 - Darwin-dev - lists.apple.com

Re: Fuse
by Uli Kusterer 18 May '07

18 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com O RLY? Elaborate :-) Cheers, -- M. Uli Kusterer http://www.zathras.de _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On 16.05.2007, at 19:44, Dan Shoop wrote: It's further clear that ad-hoc filesystems are anathema to production. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Fuse
by John Davidorff Pell 17 May '07

17 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:from:subject:date:to:x-mailer; b=jXFo5ZJcNSA3mM0+/a0t+YK7Irv3DI2J+TnmCiDa0vHV21hU8D+wcarKqsK4od+b9x75gl0rxpaRbArTtdVs9eOGd38smu99ocyXk2/zMtZWhOEJQ5s2su0pFk4PjLs51I6B2NtnjpmPo6OuTnVR7EJnLT4dvd6o9eNe7cnfh80= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:from:subject:date:to:x-mailer; b=gLWcveF0Zq0t39veAlby8Cf3s67WmYwlN+LLtNSE0zjl0xg13dyRJoEssMN6K7yBKmkA/UUsJXqqyvMEeJrgeX+metYPyzfMmmZLXzcgXU3fnSU2n2OT0KJHG9a3+MkKRKqsNjsDrzWkWPK5tJ3+XPZRzpnmTh/YmUXLrywdEAE= JP On May 16, 2007, at 10:44 AM, Dan Shoop wrote: I wasn't aware I looking for anything. Did you mean responsiveness? I know who's working on it. Dan, I had hoped that you would keep your pointless semantics arguments to the server lists. And what are you doing? You do realise that, for example, webdavfs does all its HTTP communication from a userspace daemon? YMMV. -- -dhan "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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/johnpell%40gmail.com -- God is dead, now the war shall never end. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com This whole discussion has been precipitated by Dan's confusion about the term "user-space". It appears that Dan thinks that "user-space" is somehow related to a user: i.e. the person sitting in front of the computer. This is not true. Arguably, "kernel-space" is more related to the user since all interactions with the user happen via hardware which is all managed by the kernel. Dan: "user-space" means not-in-kernel. That's all it means. The WebDAV filesystem driver is mostly user-space, and is also "system- space", as you call it. FUSE has nothing to do with "system-space" or not "system-space", a term which you have made up, it seems. The question by the OP was whether or not FUSE ought to be shipped with the system, allowing the WebDAV daemon to be moved to a better API and allowing other file systems to be in user space as well. Keep in mind what user space means: not-in-kernel. It does not imply not- production-quality. If it did, then no computer software anywhere would be production-quality (except emacs-compiled-into-the-linux- kernel). Dan: In the future, please learn the terms being used before adding your $0.02. 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(a)iwiring.net> wrote: It quite arguably is a filesystem. It's just not *a* filesystem but a hook for arbitrary filesystems. 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. 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. 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. ---------------------------------------------------------------------- -- Dan Shoop AIM: iWiring Systems & Networks Architect http:// www.ustsvs.com/ shoop(a)iwiring.net http:// www.iwiring.net/ 1-714-363-1174 ---------------------------------------------------------------------- -- This email sent to johnpell(a)gmail.com smime.p7s

1 0

Re: Can't remotely access CVS
by Tron Thomas 17 May '07

17 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 1.5.0.10 (X11/20070302) Hi, your problem description misses the most important bit of information: how are you trying to access the repository? pserver? cvs over ssh? I am trying to access the CVS respository using pserver. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I've been running a CVS server on my PowerMac system from quite a long time. Recently I've tried to log in remotely and it fails saying there is no such repository. I checked the file system and the repository is still there. I also made sure I was specifying the path to the repository correctly when I log in. I think a recent software update or something like that might have screwed up my pserver configuration. felix This email sent to site_archiver(a)lists.apple.com

1 0

Re: Fuse
by Graham J Lee 17 May '07

17 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 16 May 2007, at 22:39, Jordan K. Hubbard wrote: On May 16, 2007, at 10:44 AM, Dan Shoop wrote: Cheers, Graham. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. That's a rather broad categorization to make and, as such, not really supportable. There are many instances where putting a filesystem in user space is a good idea: BTW [to the list, not necessarily to JKH] - check out the HURD, where almost any problem can be fixed by recompiling and restarting some user-land process. There's a kernel-space module for e2fs, but that just brings the system up to a point where it can launch the userspace e2fs translator and get on with some real work ;-) On a PPC Mac, it'd be easy to imagine a scenario where the system only relies on the Open Firmware HFS+ reader until it's loaded a userspace HFS+ translator. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Fuse
by Jordan K. Hubbard 16 May '07

16 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Fuse
by Finlay Dobbie 16 May '07

16 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RuuT+7Gg7JZOM6yIq4QA8ICcXu/7WSwB8QON+T0CvYw0rM9CQDHYa6bhB+7eKpC0maikig7PwWm5/tE6IuzYB9HyrY4UB2oFQJNXEk4xs9nAtE2uGM7fFk+9dCDoNTlV2kVnC+Z4xL78V56poMAn2fNNTH4lf3NuZuTDyZsEmEY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ayXVvCINmbiJ4bIPcV96XVET/d7hwA1Lxo4NT+AOh0LUyzYmEKtLeb8dw+KCdNoZguFP62nFj1t/x8xllgBxRd72dOdINUOSwrRsJhiwTnHj3Xe/eny2rjP6OrqmUnGEj2k9GBMejV/oC9xpq999xfRVDMjALSj8sH8dPazRkuo= I'm not entirely (at all) sure why "ad-hoc" is relevant here; it makes no difference to the way the code is implemented, it's simply a matter of use-case. FUSE is an enabler, nothing more, nothing less, and on that token the fact that it CAN be used to implement ad-hoc filesystems which themselves MIGHT be unsuitable for a production environment is completely immaterial. Not to mention, it's perfectly supported in Mac OS X as it stands to implement third party filesystems as a VFS plug-in, and thus put it in a position where it is quite easy to bring down the entire machine. Besides that, I'm not really sure what an "ad-hoc" filesystem is. I can't really think of any meaningful definition, and if we don't get that sorted out, Dan will suddenly come back in a few posts time and complain that we've all misinterpreted him. Having said that, he'll now come and ridicule me for being so stupid as to not know what he meant, because it's patently obvious, but avoid defining it in any tangibly useful manner. Apologies if this is coming across as a baseless ad hominem, or feeding the troll. -- Finlay _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On 16/05/07, Mo McRoberts <mo(a)nevali.net> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Re: Fuse
by Mo McRoberts 16 May '07

16 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 16-May-2007, at 18:44, Dan Shoop wrote: -- mo mcroberts :: mo(a)nevali.net :: http://nevali.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. I'm not entirely (at all) sure why “ad-hoc” is relevant here; it makes no difference to the way the code is implemented, it's simply a matter of use-case. FUSE is an enabler, nothing more, nothing less, and on that token the fact that it CAN be used to implement ad-hoc filesystems which themselves MIGHT be unsuitable for a production environment is completely immaterial. Hey, guess what. exec...() is used to execute programs on an ad-hoc basis. Some of those programs might be dangerous and unsuitable for production use. By your argument regarding FUSE, the supporting kernel-level functionality that provides the exec family of system calls should never have been implemented. (As an aside, the assertion that WebDAV via FUSE would somehow be a step backwards as compared to its current implementation is more than a little dubious: do you actually have any basis on which to make that claim—besides “it ain't broke”? Implementing a user-space filesystem handler in a manner designed specifically to enable user- space filesystem handlers to be used seems anything but a step backwards). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Fuse
by Dan Shoop 16 May '07

16 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)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(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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(a)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(a)lists.apple.com

1 0

Re: Can't remotely access CVS
by Felix Kronlage 16 May '07

16 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organisation: bytemine - http://www.bytemine.net/ User-agent: Mutt/1.5.12-2006-07-14 On Tue, May 15, 2007 at 09:29:48PM -0700, Tron Thomas wrote: Hi, > I've been running a CVS server on my PowerMac system from quite a > long time. Recently I've tried to log in remotely and it fails > saying there is no such repository. > I checked the file system and the repository is still there. I also > made sure I was specifying the path to the repository correctly when > I log in. I think a recent software update or something like that > might have screwed up my pserver configuration. your problem description misses the most important bit of information: how are you trying to access the repository? pserver? cvs over ssh? felix -- bytemine - Entwicklungsmanufaktur fuer innovative Loesungen Geschaeftsfuehrer: Felix Kronlage - kronlage(a)bytemine.net Tel: (+49)(0)441 - 36116410 Fax: (+49)(0)441 - 36116419 http://www.bytemine.net/ - info(a)bytemine.net Kommunikation gerne mit GPG/PGP: 0xD9AC74D0 http://www.byteshare.de/ - sicherer Austausch von Dokumenten! _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com pgpxcgH81WUZW.pgp

1 0

Can't remotely access CVS
by Tron Thomas 16 May '07

16 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This might be a bit off topic. I'm not sure where to post for help on this. I've been running a CVS server on my PowerMac system from quite a long time. Recently I've tried to log in remotely and it fails saying there is no such repository. I checked the file system and the repository is still there. I also made sure I was specifying the path to the repository correctly when I log in. I think a recent software update or something like that might have screwed up my pserver configuration. What can I do that will allow me to remotely access my CVS repository again? This email sent to site_archiver(a)lists.apple.com

1 0