fix README

README

@@ -1,88 +1,3 @@
-This is a Mono/.NET binding for FUSE.
+This is a .NET Standard binding for FUSE, port of [mono-fuse](https://github.com/jonpryor/mono-fuse) library.
 
-Short HOWTO:
+For documentation see [here](http://www.jprl.com/Projects/mono-fuse/docs/).
-
-Within one terminal:
-	sudo /sbin/modprobe fuse  # need FUSE kernel module to use.
-	./configure
-	make
-	cd example/HelloFS
-	mkdir t
-	./hellofs t
-
-Within another terminal
-	cd example/HelloFS
-	ls t
-	cat t/hello
-
-This should display files controlled by HelloFS.exe.
-
-To unmount the filesystem, you need to use the `fusermount' program:
-	cd example/HelloFS
-	fusermount -u t
-
-KILLING THE FUSE PROGRAM IS NOT ENOUGH.  The program will die, but 
-FUSE and the kernel will still think that the directory is mounted.
-Result: you can't remount the directory, and trying to do anything
-with it will result in IO errors.
-
-For full trace output, set the MONO_TRACE_LISTENER environment 
-variable and add the -odebug command-line argument:
-
-	cd example/HelloFS
-	MONO_TRACE_LISTENER=Console.Out### ./hellofs -odebug t
-
-MONO_TRACE_LISTENER controls the Mono.Fuse trace output, while 
--odebug controls the libfuse-generated trace output.
-
-`hellofs' also takes its own command-line aruments.  By default, 
-it exports two files, `data' and `hello'.  `hello' contains the 
-string "Hello World!", while `data' is a 100 MB (base 10) file that 
-generates its content on-demand.
-
-If you pass the --data.im-in-memory flag, a `data.im' file will be 
-available which is a 100MB (base 10) file with the same contents as 
-`data', but it is backed by a 100MB byte[] instead of generating its 
-contents on demand:
-
-	cd example/HelloFS
-	./hellofs --data.im-in-memory t
-
-The 100MB byte[] is allocated the first time the contents of 
-`data.im' are read.
-
-`data.im' is useful to see the difference in performance between
-generate-on-demand and cached behaviors:
-
-	cd example/HelloFS
-	./hellofs --data.im-in-memory t
-
-	# On-demand copy
-	time cp t/data f.txt
-		real    0m8.469s
-		user    0m0.020s
-		sys     0m1.128s
-	
-	# In-memory copy
-	# Note that the first `data.im' access is longer
-	# because it needed to allocate the array.
-	# Subsequent calls are shorter:
-	time \cp -f t/data.im f.txt
-		real    0m12.393s
-		user    0m0.004s
-		sys     0m1.172s
-	time \cp -f t/data.im f.txt
-		real    0m5.233s
-		user    0m0.016s
-		sys     0m1.136s
-	
-	# And for comparison, cp without FUSE:
-	time cp f.txt f2.txt
-		real    0m10.252s
-		user    0m0.016s
-		sys     0m1.000s
-
-And yes, on my machine it's faster to go through FUSE than to go 
-through the filesystem (though usually the filesystem outperforms 
-the on-demand generation).  My machine is probably misconfigured. :-/
-Your mileage will vary.