Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

github.com

Post reply on HN
Print view View original

31–40 of 73 posts

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#31

Post by inkyoto »

Reason077 wrote: post #9

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

> […] Apple’s war on kexts

Hardly a war, a rather rational decision it is – they are progressively moving kernel modules, drivers, file systems and network components into the user space.

It is a foundational design principle of GNU Hurd where everything, apart from the microkernel server, runs in the user space. Minix 3 followed the same principle, and many other microkernel designs as well.

It makes sense from the resilience point of view where a defective kernel module / driver can no longer crash the entire system.

It also makes sense from the security perspective on – the kernel itself is cryptographically sealed off and can't be tampered with.

Previously, the overhead of extra context switches was too high on the old CPU's and hardware, but today's computing devices are fast and the hardware is more optimised, so moving stuff into the user space is viable and incurs a much smaller performance penalty.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#32

Post by mcpackieh »

inkyoto wrote: post #31
Reason077 wrote: post #9

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

> […] Apple’s war on kexts Hardly a war, a rather rational decision it is – they are progressively moving kernel modules, drivers, file systems and network components into the user space. It is a foundational design principle of GNU Hurd where everything, apart from the microkernel server, runs in the user space. Minix 3 followed the same principle, and many other microkernel designs as well. It makes sense from the…

"War on __" doesn't imply an irrational war on __

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#33

Post by duped »

comex wrote: post #17
duped wrote: post #15

Earlier quoted context omitted.

> they still haven’t come out with a proper API for implementing local user-space filesystems. They have, it's called a File Provider Extension (0). The major downside is that it's extremely limited in what you can provide and it's an extension of the interface on top of APFS and not a proper file system in user space. Frankly, I don't think Apple cares about creating features that would interfere with their own offe…

I'm not sure "interfere with their own offerings" is quite the right framing. It's more about "going beyond their imagined use case". iCloud Drive is a File Provider. Third-party services that want to do the same kind of file syncing as iCloud Drive, and thus compete it with it, can. And there are several highly-popular competitors that have recently moved to File Provider, like Dropbox and Google Drive. But when the…

My point is their view of a file provider is as a remote file storage API. This is one of the use cases of a file system in user space, but quite different from them generally. Most of the interesting use cases that FUSE covers are completely unsupported by the File Provider API.

And I believe this is because they want anything that might be useful but competitive with the features they provide their users to be hamstrung by the same design contraints of iCloud and APFS.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#34

Post by [deleted] »

kelnos wrote: post #8
fathyb wrote: post #4

Earlier quoted context omitted.

Does not answer your question directly, but related: https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... > The project consists of two components: libfuse and fuse-t server. libfuse is LGPL licensed and can be downloaded from here: macos-fuse-t/libfuse [1]. You can modify and build it as you wish, the build instructions are provided in the README file. The fuse-t server on the other hand is a proprietary…

Weird that early in the issue comments the author claims they're going to release source for fuse-t, but then later in the comments changes course and says it's proprietary. Sounds like they originally wanted to release it as open source, but under a restrictive non-commercial license (which is fine, I guess), but then has gone back on that promise. I'm not gonna be one of those "proprietary software is immoral" peop…

[deleted]

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#35

Post by soraminazuki »

fathyb wrote: post #4
PlutoIsAPlanet wrote: post #2

Why is there a GitHub and no source code?

Does not answer your question directly, but related: https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... > The project consists of two components: libfuse and fuse-t server. libfuse is LGPL licensed and can be downloaded from here: macos-fuse-t/libfuse [1]. You can modify and build it as you wish, the build instructions are provided in the README file. The fuse-t server on the other hand is a proprietary…

I respect the author's choice to use a proprietary license, but I wish they'd been honest about it.

I've been tracking that GitHub issue when FUSE-T came out. Initially, the author promised to open source. But then there was a long silence, after which the issue was closed as "completed" without any explanation.

It's unfortunate because proprietary software requires more trust for users. The lack of communication demonstrated here is concerning.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#36

Post by iknowstuff »

mcpackieh wrote: post #32
inkyoto wrote: post #31

Earlier quoted context omitted.

> […] Apple’s war on kexts Hardly a war, a rather rational decision it is – they are progressively moving kernel modules, drivers, file systems and network components into the user space. It is a foundational design principle of GNU Hurd where everything, apart from the microkernel server, runs in the user space. Minix 3 followed the same principle, and many other microkernel designs as well. It makes sense from the…

"War on __" doesn't imply an irrational war on __

Only if you’re a stickler. It does assume an opponent and has a negative connotation

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#37

Post by donatj »

vbitz wrote: post #22
donatj wrote: post #19

Earlier quoted context omitted.

I wish everyone would just standardize on 9p already. It's solid and has existed for going on thirty years. Microsoft actually uses it for WSL, but afaik does provide the ability to access other 9p servers.

9p involves a lot of round trips to create/write files. I benchmarked sshfs using fuse vs. 9p in the kernel and sshfs was significantly faster.

Perfect is the enemy of good, and 9p is great.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#38

Post by MyelinatedT »

mathiasgredal wrote: post #10

What prevents Apple from just integrating MacFUSE(or a reimplementation) into the their kernel, and then shipping it with the next release?

If they ever do this, it’ll probably take the form of a proprietary userspace FS interface that will only work through Finder and will require the binary to be downloaded from the Mac App Store or otherwise signed by Apple. Every dev that wants to use it will have to pay Apple for the privilege.

But maybe I’m just being cynical.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#39

Post by the8472 »

donatj wrote: post #19
Reason077 wrote: post #9

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

I wish everyone would just standardize on 9p already. It's solid and has existed for going on thirty years. Microsoft actually uses it for WSL, but afaik does provide the ability to access other 9p servers.

9p is a network protocol. For machine local filesystems one can do better by making use of shared memory which fuse and virtio-fs do.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#40

Post by donatj »

the8472 wrote: post #39
donatj wrote: post #19

Earlier quoted context omitted.

I wish everyone would just standardize on 9p already. It's solid and has existed for going on thirty years. Microsoft actually uses it for WSL, but afaik does provide the ability to access other 9p servers.

9p is a network protocol. For machine local filesystems one can do better by making use of shared memory which fuse and virtio-fs do.

It's a network protocol as far as everything from Plan9 was designed to be able to operate over the network in the late 90s sense of " the network is the computer". The local file system of Plan 9 though is exposed locally through 9p
Post reply on HN