Hi Graham, Graham Perrin wrote: >> We'll just have to work together as a community then, to fix any >> Snow Leopard issues >> > > Distinguishing between 64-bit processing, bitness of the kernel, Snow > Leopard Server and Snow Leopard: > > * what's the rush to have MacFUSE (*user* space) working with a 64-bit > kernel in a > _server_ version of the OS that's not intended for end users? >
Whether or not it's intended for end users, the 64-bit kernel does work for end users (even on non-server Snow Leopard), and a lot of users are running the 64-bit version of the kernel, whether they should or not. (I don't think they should, but they obviously have a different opinion.) They don't consider MacFUSE and associated file systems to completely support Snow Leopard if it can only run on one kernel flavor out of two. I get these complaints daily for NTFS-3G. > I don't devalue any community work in progress, but I wonder whether > development of MacFUSE should focus, currently, on issues that affect > the more common version of 10.6. > That is more important, agreed. However, there doesn't seem to be many issues when running the 32-bit kernel, afaik. > (Issues that affect MacFUSE on 10.6 Server in 64-bit kernel mode may > take a sideline. Assuming that it will be some time before there exist > enough everyday drivers etc. to make a 64-bit kernel practical for the > masses using ordinary Snow Leopard.) > > Is my view of things too simplistic? > I think this is more than a single issue that needs to be fixed. The real issue is that a lot of projects have come to depend completely on MacFUSE, which inself seems to depend more or less on one person, Amit. It seems that today the entire MacFUSE based ecosystem sort of rests on his shoulders, which makes it all very vulnerable. While this approach works for experimental software in a development phase, MacFUSE has matured to the point where it's in use by many independent projects, some commerical and some not, many striving to deliver quality software that works on the latest platforms. If the main MacFUSE project isn't progressing, then each project using MacFUSE could of course try to fix any issues that exist, but a coordinated community effort would in that case be preferable, to avoid that each project ships its own locally modified version of MacFUSE (imagine the nightmare). For the main project, my opinion is that the group involved in developing/maintaining MacFUSE should be broadened, or the project could eventually die out. I think you can agree with me that it is a problem that we are sitting here today, not knowing if or when MacFUSE will be updated to deal with the issues that apparently do exist. A public statement or announcement regarding future plans for the project would be much appreciated. I'd like to thank Amit for all the amazing effort he has put into this. He really opened a whole new horizon of possibilities for Mac file systems. I could easily understand if he's not willing to continue working in his spare time just to satisfy grumpy file system developers. :) The problem is that I do now know how to plan for the future, and I think more developers than myself could agree. Cheers, - Erik --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
