Everybody, please realize that when I say "shared resource", it is *different* from typical scenarios and experiences that involve userland-only software. I am not talking about redundancy. I am not talking about disk or memory footprints. Aside from redundancy, with userland stuff, it is still possible, one way or another, to make applications use private versions of libraries or bundles--without interfering with other applications.
The MacFUSE situation is quite different. MacFUSE has a kernel extension too, which is the global/system-wide resource I am talking about. You can't just fork the kernel namespace and replicate in-kernel MacFUSE instances. Besides being a different situation, it's also a unique situation. (Think about whether it is common for many Mac developers/vendors to build atop a kernel extension that's not shipped by Apple.) Developers' needs and concerns (about new MacFUSE releases breaking their software) may be real in their minds, but each party shipping their own kernel extension is a bad idea. Just because you shipped the version you like won't stop some other vendor to clobber your version with a different version they like, so how does that help? If packaging errors happen, it would be hard or impossible to even track whose package is causing what. (You could end up with one vendor's binaries but another vendors receipts, etc.) Even if you install things at different locations on the disk (like Fink does, I believe), the kernel extension still goes into the same namespace in memory! The correct way to *begin* to address this issue is to fully understand the implications of what MacFUSE is (a kernel component). As core pieces of Mac OS X get updated, do vendors continue shipping older pieces of Mac OS X (!!!) with their software? If you depend on some quirks in HFS+, would you ship older OS X kernels? Well, legally you couldn't, but if you could, would you? So, as far as this "issue" is concerned, I would ask developers to deal with it the same way as they deal with Apple's system components. MacFUSE's goal is to never break the API it exports to you guys. MacFUSE will try its best to not break the contract. Sure, bugs could happen--as they do with any other software, but if everybody cooperates, we can minimize unnecessary issues for everyone. Speaking for myself, I'd like to spend the little time I have on improving the core rather than dealing with support issues that shouldn't be there in the first place. The other issue that I do recognize as more real is that of getting MacFUSE onto the user's machine. I've been toying with the idea of providing a common module (a library or whatever) that file system developers could use (at install time or run time) to check for MacFUSE availability, and if necessary, offer to download and install the latest stable version of MacFUSE from the official repository. The module could even support keeping MacFUSE up-to-date. We can talk about this once (if) we all get on the same page about the "globally shared" semantics of MacFUSE. Amit On Jun 12, 10:10 am, "ted bonkenburg" <[EMAIL PROTECTED]> wrote: > On Thu, Jun 12, 2008 at 8:33 AM, Dave Koziol <[EMAIL PROTECTED]> wrote: > > > For Missing Sync for WIndows Mobile, we us a Meta Package for our > > installer, and we just have MacFUSE as one of the various packages we > > install. This allows us to ship the MacFUSE package as delivered. In > > the event someone turns off MacFUSE in our installer, and tries to use > > our functionality which requires MacFUSE we just tell the user to go > > reinstall. While it is possible for the users to customize the > > installer, the reality is that most users don't do this, and if they > > do they just need to run the installer again. > > Thanks for adding another data point to this discussion. > > Offtopic: I'm curious what Missing Sync for Windows Mobile is using MacFUSE > for. > > I've seen the PackageMaker issue with at least one other product aside > from ExpanDrive. It seems that PackageMaker will re-write the bundle > identifier and version string as well as remove whatever was in the > Resources directory when you drag a .pkg into the interface. Please > double-check the MacFUSE Core.pkg in your created .mpkg to make sure > that this isn't happening to you as well. > > I've been told that this problem does not seem to occur if you use > Iceberg to create .mpkgs. > > > > > Our only "issue" with the Package as currently distributed is that the > > info.plist file contains a IFPkgFlagInstalledSize with a size of 0. > > This results in a less than ideal experience and we currently work > > around this by removing that key from the Info.plist file. But we'd > > like to see the next release of MacFUSE built in such a way that this > > is no longer required by us. > > Can you describe what the less than ideal experience is? Is it simply > that it doesn't tell you in advance the estimate of how much disk > space it'll take up or is there something else that I'm missing? It > looks like if I remove the key from the Info.plist.in that is used to > generate the "MacFUSE Core.pkg" then it will be created and filled in > properly by packagemaker. I'm happy to get that change in for the next > release if it solves your issue. > > In the future, please don't hesitate to let us know about such issues. > I won't guarantee that we'll fix things, and we might disagree about > what needs fixing or how things should be changed, but if we don't > even *know* that you are having a problem then it doesn't help > anything. > > > > > I would agree with the others, we would really prefer to see everyone > > distributing the standard MacFUSE and working to resolve any problems > > in that distribution rather than customizing the installation. Is the > > version number in svn kept in such a way that we at least have a hope > > of detecting someone who has a version of MacFUSE built from the trunk > > as opposed to an official release? > > Our current practice is to tag the tree when we do an official release > and then increment the version number in svn. > > I'm not too worried about people who build and install from the head > of the tree on their own. If they can manage that then I expect them > to be savvy enough to realize why MacFUSE-based file systems they are > using might have problems. Really only developers should be doing > this. I also think this case is extremely rare. > > What I do worry about is people distributing builds from the head of > the tree. I think we can all agree that this is a bad idea. > > ted > > > > > On Jun 12, 2008, at 11:01 AM, Jon Shea wrote: > > >> Hi Amit, Dave, and Ted, > > >> I work with Jeff at Magnetk. I'm concerned about our MacFUSE > >> distribution problem as well. We need to distribute MacFUSE with > >> ExpanDrive; we'd consider it an unacceptable user experience if our > >> users had to install MacFUSE themselves. But we can do a better job of > >> it. > > >> In the future we will have ExpanDrive check the installed version of > >> MacFUSE, and offer to upgrade if necessary. If the user declines to > >> upgrade, then we will refuse to run. We will also fix the issue with > >> our MacFUSE installer, including existing installations. As long as > >> we're installing MacFUSE as a shared resource it's important that our > >> installation be exactly the same as yours, and it's embarrassing that > >> our mistake makes the uninstaller fail. I apologize. > > >> I think that a lot of libraries present present a dilemma as to > >> whether they should be installed as a shared resource, or if they > >> should be installed separately by each vendor (Gems in Ruby on Rails > >> applications, or the Sparkle framework, for example). If each vendor > >> installs their own copy, then system resources are wasted on > >> redundancy. > > >> But if every vendor shares the same installation, then they have to > >> trust every other vendor to be a good citizen when it comes to > >> managing that library. Even if every version of MacFUSE is perfectly > >> backwards compatible, it's possible that a filesystem will "depend" on > >> a bug in MacFUSE, and that the filesystem will break if MacFUSE is > >> upgraded by a different vendor. > > >> There's no perfect solution to this dilemma. As the number of MacFUSE > >> filesystems in use increases, we're likely to run into it again. With > >> that in mind, we want to do everything we can to be a good citizen. > >> Thank you for your help. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" group. To post to this group, send email to macfuse-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse-devel?hl=en -~----------~----~----~----~------~----~------~--~---
