I'll make a pkg and an iceberg file to continue distributing this with. The only downside with iceberg is that it 
runs a root owned process, but it can be turned off once it's done.

Here's a preliminary one and the associated pmproj file I used.

Note the postflight script which loads the kext for you if the target volume matches
the boot volume.

	MacFUSE-0.1.0b004-3.pkg.dmg
	8.9 MB Download

	MacFUSE-0.1.0b004-3.pmproj
	2.6 KB Download

	postflight
	874 bytes Download

Hrmm, using pmproj is probably better. I'll leave it to you mccune.jeff since you've already got that done.

I'm afraid we currently have no plans to release or maintain binary package (We reserve the right to change our 
mind, of course :-)) The binary package made available today was a one-time convenience thing done so that 
early (earliest) adopters could try things without much inertia.

I gather from the license that third parties are permitted and encouraged to maintain binary packages, provided 
they take up the support responsibility? :-)

Why create something great like this and don't create a binary package? That's like
inviting all your friends to a great party and don't open the door :(.

Really. This is Mac OS X, not Linux. Not releasing binaries is pretty much equivalent
to not releasing at all!

Tough crowd. I'll see what we can do.

I disagree; I don't think a package installer should be made available yet.
From what I gathered, this is not yet ready for mainstream usage. It needs more
testing, etc.
When most people agree that it's stable, then a binary installer could be made
available to reach the 'common mac user'. Until then, only 'early adopters' /
enthusiast should install this.

copy/pasting commands from a wiki page to install sucks ;)

asingh, please don't be discouraged by the "demand" for a binary package.  I
personally would rather compile and package MacFUSE if it gives you and your team
more resources to develop and release incredible software like this.

As I continue to compile and package, should I update this ticket with the new files,
or would you prefer I take the packages off-site to something like afp548.com to
ensure everyone understands google is not releasing and supporting these community
binary packages?

Thanks again for MacFUSE.  I was more excited by your presentation than the keynote.  =)

asingh, please don't be discouraged by the "demand" for a binary package.  I
personally would rather compile and package MacFUSE if it gives you and your team
more resources to develop and release incredible software like this.

As I continue to compile and package, should I update this ticket with the new files,
or would you prefer I take the packages off-site to something like afp548.com to
ensure everyone understands google is not releasing and supporting these community
binary packages?

Thanks again for MacFUSE.  I was more excited by your presentation than the keynote.  =)

Here's a 0.1.0b006 Package.  I'll be naming all further packages "MacFUSE.pkg" to
prevent a ton of folders being created in /Library/Receipts.  I've also changed the
package to recommend, but not require a restart and attempt to unload the kext to
ease upgrades.

	MacFUSE-0.1.0b006-1.pmproj
	2.6 KB Download

	MacFUSE-0.1.0b006-1.dmg
	8.9 MB Download

	MacFUSE-0.1.0b006-1.dmg.asc
	189 bytes Download

I'm unable to successfully download the MacFUSE Package uploaded by jeff.
It fails before fully downloading it. I would suggest moving the package to another
server and giving it a proper home, since the binaries are going to change regularly
(and this is not it's home)...

We're providing an *unsupported* package based installer. I'm leaving the tarball in
place too for the time being. Please try out the installer and verify that it works.

Hello, I do not understand why you instal fuse.kext in /System/Library/Extensions. This folder is reserved for 
Apple usage, and you can use the /Library/Extensions folder that is reserved for third-party extensions.
Is there a special reason?

While /System/Library is indeed generally reserved for Apple's use, there is no third-party equivalent for 
/System/Library/Extensions in particular. /Library/Extensions is non-standard.

http://daringfireball.net/2003/08/the_one_and_only_mac_os_x_extensions_folder pretty much says it all; 
although three and a half years old now, things haven't really changed since. XNU still, to my knowledge, only 
looks in that one directory. The mailing list post Gruber links to ( http://lists.apple.com/archives/darwin-
development/2002/Dec/msg00083.html ), while yet another year older, also contains some more insight.

So, the special reason, in essence, is that there is no true alternative.

Some vendors (including yours truly) do use /Library/Extensions, but only through manually loading those 
extensions. Since FUSE is more general-purpose, it ought to be available for automatic loading, and that 
makes /System/Library/Extensions the only viable location.

Thank you for this explication. I better understand now.

There is a package-based installer now.

The package based installer is great.  Thanks.  Gorgeous icons too; the extra touch
is nice.