Am 21.06.2011 um 23:15 schrieb Anatol Pomozov: > 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.
I'm not saying we should distribute "MacFUSE.framework" but there should not be a problem setting up a symlink or something like that pointing to OSXFUSE.framework or Fuse4X.framework for that matter. If the frameworks are binary compatible everything should continue to work just fine. Another thing we should investigate is the possibility for a *.Framework bundle to contain different version of the same framework. This could be a solution for the future to remain compatible with the latest official MacFUSE release. Have you already tried this or something similar? I don't see how this could cause any legal issues. In the end we are not distributing MacFUSE.framework. > > 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. I haven't tested Fuse4X on Leopard either but I think support for Leopard is vital for its adoption by filesystem developers. > 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. I'm not sure what you mean. Let me explain what I meant: We need only one MacFUSE fork not two or three. - The first release of this fork should stay as close as possible to the original MacFUSE code (Fuse 2.7.3, 64 bit support for Snow Leopards kernel, Xcode 4 compliant) supporting 10.5 and 10.6 (Intel only) but rebranded as whatever. - The second release of this project fork should integrate support for Lion. Not sure how much work that will be. In the end we should have support for 10.5 through 10.7 (Intel only though) - The following releases should bump libfuse to 2.8.5 and later 2.9 among other changes. I think we should not jump the gun and start with step three. > > 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. I don't know. For what it's worth I suspect we would have already seen this in the latest developer preview if this feature was in fact right build in. In that case continuing development on a MacFUSE fork seem less appealing to me. > 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 know ... > I am going to look at it in the next few weeks. Appreciated. > 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.
