I'm really happy to see these efforts underway! I would be happy to help test any builds as they are ready for consumption. I've been using the Tuxera build and it has been fine for the most part, although it seems to suffer from kernel locking problems according to messages spit out to my system logs/Console and lags that I suffer during these times. I don't know if this is a known issue (my volume is served via SSHfs), but basically my only real desire is for an official supported build without this particular problem. Like I said, I'm happy to test builds whether they require compilation or installation via binary/disk image.
I have noticed that an old version of libfuse is in use as has been discussed in the past here. Are the benefits of eventually getting MacFUSE linked against newer versions of this library tangible in terms of performance, reliability, or anything else? I do know that newer versions of s3fs require newer versions of libfuse, so this is one obvious problem, although I have no clue how s3fs would otherwise fare in OS X. > Peter <mailto:[email protected]> > May 5, 2011 8:03 PM > > > I think this thread is important enough that I feel obligated to share > thoughts as a MacFUSE user. > > First of all, I really appreciate Anatol's efforts into putting up a > new home. There is clearly a need for continuation of MacFUSE and > without Amit, we're essentially stalled on the official development. > Also, Google Groups seem to have been flooded by recruitment emails > lately, for whatever reason. It's natural that someone should take the > project to Github and hopefully the development can continue. Benjamin > has pointed out great questions that's also on my mind. Before going > forward with the creation of repository and websites, I feel it's > important to agree on the answers. > > I personally think Eric Larsson has demonstrated great understanding > of MacFUSE internals and good faith with his commits to allow 64 bit > locking possible on x86_64 kernels. I'd personally like to see him > being the gatekeeper for repository and owner of the private key. > Thanks a lot Eric for your great, and kudos to Tuxera for releasing > Eric's work. I think as long as Tuxera continues to uses MacFUSE for > their NTFS3G for Mac, the company will have business interests to make > MacFUSE as stable and robust as possible, but it also means as long as > MacFUSE works good enough, there's no point to spend additional > development effort. I think that's the current status of their > branch. > > I also think Benjamin has showed great passion in the project with his > 2.1.7 release for back porting Eric's release of tufs into MacFUSE > svn. He has also demonstrated good knowledge on MacFUSE when helping > other users and distinguishing the difference between various 64 bit > ports in his responses. His patch to buildtool also makes building > possible. > > From what I learned on threads in this group, I'd like to see the > following: > > 1. Private key owner: Eric, and he decides which is official build > 2. Commit privilege: Eric, Ben > 3. Edit wiki: Eric, Ben, Anatol > > I don't necessarily think we need to use macfuse.org, signed binary > can be added to github so there won't be any issue on ownership of the > domain in the future. I like MacFUSE as the project name but I also > have no knowledge on the legal side. > > Again, all of the above are my personal thoughts based on threads I've > read up to this day, and my apologies if you feel you are qualified > but I didn't mention. > > Peter > > ------------------------------------------------------------------------ > > Benjamin Fleischer <mailto:[email protected]> > May 5, 2011 6:06 PM > > > Am 05.05.2011 um 21:02 schrieb Anatol Pomozov: > > > There a several questions that need to be answered before this > happens. Correct me if I am wrong but from what I can see you started > posting to this mailing list about three weeks ago and now you want to > be the new project head. Did you do any development on this project in > the past? But most importantly you did not really tell the rest of us > what you plan to do besides importing all the patches floating around > and see where it leads. > > - What about the name MacFUSE. I guess having two "official" MacFUSE > projects will lead to problems or at least confusion. If you just use > MacPorts everything might be fine but if you google it there will > always be two "official" projects. What if Amit decides to pick up > development again or pass it to someone else (I don't think so, but > who knows)? Amit seems to have started a commercial counterpart to > MacFUSE called NuFS (Have a look at h > <http://iohead.com>ttp://iohead.com > <http://iohead.com/NuFS/index.html>). Using the name MacFUSE won't > work unless the original google code project points to the new project > page or "disappears". I don't see that happening at the moment > (conflict of interests). What do you think? > > In addition to that I'm not sure if adopting the name MacFUSE could > lead to legal troubles. I have no legal degree or something like that > so correct me if I'm wrong but MacFUSE belongs to Google. Amit has > been an Google employee. > See http://code.google.com/p/macfuse/source/browse/trunk/COPYING.txt > > - What Mac OS X versions should be supported? I would suggest dropping > support for 10.4 and 10.5. The existing MacFUSE versions 2.0.3 and > beta 2.1.5 run just fine on 10.4 and 10.5. That will make development > a lot smoother in the end. Supporting 10.6 (Intel) and later 10.7 > should be sufficient for new releases. BTW is there anybody who has > access to 10.7 and is willing to contribute? > > - Who decides which code makes it into the "official" tree? In other > words who will have write access to the repository and who will be in > charge? > > In the end just collecting patches won't do the job. > > I started where you are now (code-wise) and am happy that I got the > whole thing (macfuse_buildtool.sh -t dist) working after investing > many hours and now you ask me to fork your code base . Depending on > the versions of Mac OS you plan to support this will be a lot of work > (since I dropped everything but 10.6 and use the 10.6 SDK instead of > 10.5 as Erik's/your code does). From where I stand, it would be far > easier if you just forked my repository :-) I'm not willing to put > that much effort into patching up everything again just to use your > code base as a starting point if the future of your project fork is > this vague. > > Getting the update mechanism to work is not just about fixing the > PrefPane (there are some bugs regarding signing and verifying a > signature nonetheless). For the whole update process to work there > need to be a RSA key pair to authenticate updates and some persistent > webspace. > > - The private key should not be publicly known for obvious reasons. So > uploading it to the repository would be a bad idea :-) Who should > possess the key? > > - I figure you plan to use a github-page (as I did) since Tomas' > domain macfuse.org <http://macfuse.org> points to github. Is this correct? > > I would suspect there are more questions that need to be answered if > working together as a community on a new project fork should have a > change of success. And of course we would need at least some dedicated > developer for this to work. > > Regards, > Benjamin > -- > 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. > ------------------------------------------------------------------------ > > Anatol Pomozov <mailto:[email protected]> > May 5, 2011 3:02 PM > > > Hi > > On Thu, May 5, 2011 at 11:06 AM, Benjamin Fleischer > <[email protected]> wrote: >> You seem to focus solely on MacPorts. > I use macfuse mostly as a library from macports so it is not a > surprise that I care about this part a lot. > > I am glad to hear that there are people who care about other parts of > the project. > >> What about the regular MacFUSE update >> mechanism (PrefPane)? The PrefPane in the official MacFUSE SVN is broken. >> Therefore I fixed it last October when I released a patched version of >> MacFUSE 2.1.7 using Erik's early stage locking code to get this thing >> working with 64 bit kernels. >> If anyone is interested in this you can find my work >> at https://github.com/bfleischer/macfuse in branch macfuse-2.1. My latest >> stable binary release (2.1.11) is based on the latest modifications from >> Tuxera (2.1.9) and can be found at http://bfleischer.github.com/macfuse/. By >> the way, the patched up PrefPane checks this github-page for updates, too. > > Great to hear it! May I ask you to send the fix as a commit based on > the current HEAD? https://github.com/macfuse/macfuse/ PrefPane fix is > definitely worth submitting to the upstream. > >> A few mid-term tasks: >> * update fuse to 2.8.5. Currently macfuse depends on horribly outdated >> 3 yo libfuse release. >> >> As I wrote a few weeks back I'm in the progress of patching fuse-2.8.5 in >> order to work with MacFUSE. >> I made some progress and have a version that >> compiles fine (with my source release and using the 10.6 SDK rather than >> 10.5 as Tuxera does) but there seems to be some incompatibilities regarding >> the kernel interface. fuse 2.8.5 uses interface version 7.12. MacFUSE >> currently only supports 7.8. >> My fuse repository can be found at https://github.com/bfleischer/fuse/ >> It contains the original fuse 2.8.5 source in branch fuse-2.8.5 and the >> patched (but far from stable) version in branch fuse-8.8.5-macfuse. Help is >> always welcome. >> A script to create a patch that plays well with the MacFUSE buildtool can be >> found in branch tools. >> >> * create a fork of libfuse and sshfs repositories. Currently diffs >> between upstream and macfuse changes is stored as a patch. >> https://github.com/macfuse/macfuse/tree/master/core/10.5/libfuse It is >> ugly. Especially if you want to look diff over diff. Instead we should >> have separate repos with 2 branches - upstream and macfuse. When you >> make a change to libfuse repo - you update the diff as well. Or even >> better - to remove *.patch files at all and just use git submodules. >> >> I would suggest one step after another. For now most MacFUSE code bases are >> still somewhat similar. If you start changing stuff like this right now we >> might get more problems than it is worth. Just my opinion. > > It makes sense. Consolidating all patches and fixes is more important task. > >> Another reason >> for the .patch file might be the different license model. MacFUSE uses a BSD >> style license whereas fuse uses GPL and LGPL. This keeps the cut clean. > > ------------------------------------------------------------------------ > > Benjamin Fleischer <mailto:[email protected]> > May 5, 2011 2:06 PM > > >> A new official release? As the current HEAD is the same as tuxera repo >> the new release will be the same as 2.1.9.dmg The reason I want it is >> to force macports to move to it. So macports either abandon their >> changes or move it upstream. This way we remove yet another source of >> confusion. > > You seem to focus solely on MacPorts. What about the regular MacFUSE > update mechanism (PrefPane)? The PrefPane in the official MacFUSE SVN > is broken. Therefore I fixed it last October when I released a patched > version of MacFUSE 2.1.7 using Erik's early stage locking code to get > this thing working with 64 bit kernels. > > If anyone is interested in this you can find my work > at https://github.com/bfleischer/macfuse in branch macfuse-2.1. My > latest stable binary release (2.1.11) is based on the latest > modifications from Tuxera (2.1.9) and can be found at h > <http://bfleischer.github.com/macfuse/>ttp://bfleischer.github.com/macfuse/ > <http://bfleischer.github.com/macfuse/>. By the way, the patched up > PrefPane checks this github-page for updates, too. > >> A few mid-term tasks: >> * update fuse to 2.8.5. Currently macfuse depends on horribly outdated >> 3 yo libfuse release. > > As I wrote a few weeks back I'm in the progress of patching fuse-2.8.5 > in order to work with MacFUSE. I made some progress and have a version > that compiles fine (with my source release and using the 10.6 SDK > rather than 10.5 as Tuxera does) but there seems to be some > incompatibilities regarding the kernel interface. fuse 2.8.5 uses > interface version 7.12. MacFUSE currently only supports 7.8. > > My fuse repository can be found at https://github.com/bfleischer/fuse/ > It contains the original fuse 2.8.5 source in branch fuse-2.8.5 and > the patched (but far from stable) version in branch > fuse-8.8.5-macfuse. Help is always welcome. > > A script to create a patch that plays well with the MacFUSE buildtool > can be found in branch tools. > >> * create a fork of libfuse and sshfs repositories. Currently diffs >> between upstream and macfuse changes is stored as a patch. >> https://github.com/macfuse/macfuse/tree/master/core/10.5/libfuse It is >> ugly. Especially if you want to look diff over diff. Instead we should >> have separate repos with 2 branches - upstream and macfuse. When you >> make a change to libfuse repo - you update the diff as well. Or even >> better - to remove *.patch files at all and just use git submodules. > > I would suggest one step after another. For now most MacFUSE code > bases are still somewhat similar. If you start changing stuff like > this right now we might get more problems than it is worth. Just my > opinion. Another reason for the .patch file might be the different > license model. MacFUSE uses a BSD style license whereas fuse uses GPL > and LGPL. This keeps the cut clean. > -- > 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. > ------------------------------------------------------------------------ > > Anatol Pomozov <mailto:[email protected]> > May 5, 2011 1:24 PM > > > Hi > > On Wed, May 4, 2011 at 3:41 PM, Tomas Carnecky <[email protected]> > wrote: >> We have a new home at https://github.com/macfuse. >> >> The sources from svn have been imported into a git repo >> (https://github.com/macfuse/macfuse). At least one of the original >> authors didn't wish his email to be publicly available, so I assigned >> all the original developers a @macfuse.org email address. A few >> details on that are available at >> https://github.com/macfuse/macfuse/wiki/Migration. >> >> The wiki pages are also on github. A conversion from google code wiki >> syntax to markdown was required. The conversion isn't perfect, but >> it's a start. We can clean it up later. See >> https://github.com/macfuse/macfuse/wiki/_pages. >> >> We can use github issues to track bugs and feature requests. >> >> Google groups seems a good solution for end-user support, unless >> someone has a better alternative. >> >> We also have the #macfuse channel on freenode, in case people prefer IRC. >> >> >> There's still lots of stuff that needs to be done: >> >> - A proper homepage for end-users (web developers/designers needed) > Ok, now we have a webpage for the macfuse http://macfuse.github.com/. > http://macfuse.org/ should be updated shortly as well. > > if you want to add anything to the site - send patches for > https://github.com/macfuse/macfuse.github.com > >> - Clean up the wiki (remove references to the old google code page etc). >> - Merge patches which have accumulated over time (macports, external >> companies which ported macfuse to the 64bit kernel etc) > It looks like we decided to go with tuxera changes, it is great! > >> Did I miss something? > > A new official release? As the current HEAD is the same as tuxera repo > the new release will be the same as 2.1.9.dmg The reason I want it is > to force macports to move to it. So macports either abandon their > changes or move it upstream. This way we remove yet another source of > confusion. > > A few mid-term tasks: > * update fuse to 2.8.5. Currently macfuse depends on horribly outdated > 3 yo libfuse release. > * create a fork of libfuse and sshfs repositories. Currently diffs > between upstream and macfuse changes is stored as a patch. > https://github.com/macfuse/macfuse/tree/master/core/10.5/libfuse It is > ugly. Especially if you want to look diff over diff. Instead we should > have separate repos with 2 branches - upstream and macfuse. When you > make a change to libfuse repo - you update the diff as well. Or even > better - to remove *.patch files at all and just use git submodules. > > ------------------------------------------------------------------------ -- Joe Auty, NetMusician NetMusician helps musicians, bands and artists create beautiful, professional, custom designed, career-essential websites that are easy to maintain and to integrate with popular social networks. www.netmusician.org <http://www.netmusician.org> [email protected] <mailto:[email protected]> -- 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.
<<inline: compose-unknown-contact.jpg>>
<<inline: nmtwitter.png>>
