Hi On Tue, Jun 21, 2011 at 12:37 PM, Benjamin Fleischer <[email protected]>wrote: > > > Fuse4X is owned and maintained by Anatol. Like MacFUSE it has just a single > owner. Though Anatol's project is based on MacFUSE he changed quite a lot. > The result is a MacFUSE successor which is binary incompatible with most > existing MacFUSE filesystems. The filesystems would need to be specifically > recompiled against Fuse4X for things to work. How likely is that? >
The thing is that you cannot rebrand the project without braking backward compatibility. MacFUSE applications are linked against MacFUSE.framework. If you decide to keep /Library/Frameworks/MacFUSE.framework/ then you have a conflict of interests with Google. Let me quote Amit from his post http://tinyurl.com/447efe4 "Among other things related to the history of the project, there's strong branding/affiliation/association of "MacFUSE" with "Google"." If you still want to keep MacFUSE framework you will have legal issues with Google then. > Keep in mind that Fuse4X is only compatible with Mac OS X 10.6. For open > source projects this would be an easy task but for commercial or in general > closed source projects this won't be as easy. That's why there could not > have been extensive testing regarding compatibility of his MacFUSE fork with > existing filesystems. From a developer's point of view this and dropping > support for 10.5 is bad. > I did not test Fuse4X with 10.5 I suspect just recompiling it with 10.5 should work. If you think that 10.5 support is important for you - send me the patch. I'll be happy to include it. > > Don't get me wrong, Anatol has some great ideas and I agree with him that > it is important to bring MacFUSE (or whatever it is called) up to speed and > restore compatibility with its Linux origin. But we should not rush things. > In my opinion it is important to first release a stable and well-tested > version of MacFUSE/OSXFUSE that does not change too much code-wise, is > binary compatible with MacFUSE and supports Snow Leopard's 64 bit kernel. > This way there is no need to recompile existing filesystems. The transition > from MacFUSE to its successor will be a lot smoother this way. The second > release should fully support Lion. This would be a basis we could build on > and adopt some more extensive code changes. > Having several open-source forks (10.5-compatible vs upstream-compatible) would be really confusing. I would really love to see only one fork. It is easier to add 10.5 support to Fuse4X instead of forking project again. Take into account that there is NuFS - another, commercial successor of MacFUSE and add here Apple insiders rumors about "something interesting in Lion" (my guess is Fuse-like macosx-specific framework). This is just too many MacFUSE successors - this is going to be very confusing both for users and developers. > > Code-wise Anatol's fork is based on Erik's kernel code to support 64 bit > kernels and my port of Linux FUSE 2.8.5 to Mac OS X. On top of that he > applied his own patches. > Fuse 2.8.5 is not totally supported yet. The Fuse API is updated, but FUSE_IOCTL and FUSE_POLL requests are not implemented in kext yet. I am going to look at it in the next few weeks. Erik and I are the "owners" of the OSXFUSE project. Once we get some things > worked out I'm all for adding contributors. I would like OSXFUSE to be > community based to prevent the situation we now have with MacFUSE and Amit > abandoning the project. > As I said many times already I am all open for Fuse4X contributors and developers. Benjamin, if you are willing to contribute to Fuse4X I'll grant you developer permissions. -- You received this message because you are subscribed to the Google Groups "MacFUSE" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/macfuse?hl=en.
