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

Userspace FUSE for macOS

fuse-t.org

Post reply on HN
Print view View original

71–80 of 137 posts

Re: Userspace FUSE for macOS

#71

Post by rgovostes »

TimTheTinker wrote: post #61
mdaniel wrote: post #6

Earlier quoted context omitted.

That "repo" appears to exist solely for housing the release artifacts, for those who came to the comments looking for "the goods" Also, https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt appears to be "playing lawyer"

> Also, https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt appears to be "playing lawyer" Do you have any specific concerns with the text of the license? The text seems clear enough that there don't appear to be any potential liabilities from using the software in a personal capacity. As I understand it, the worst that could happen is that the license/software author could unknowingly incur liabilities from…

For one thing, they copied the clauses from the BSD license, including references to “the following disclaimer”, but omitted the disclaimer itself.

Re: Userspace FUSE for macOS

#72

Post by jbverschoor »

userbinator wrote: post #65
jbverschoor wrote: post #28

Why does everybody use tcp ports instead of file sockets for local communication?

Because TCP is well-known and works both locally and over the network, on just about every networked operating system?

It’s not almost enough for all developers to not just simply bind to 0.0.0.0.

It’s not well known enough, looking at the recent thread where people are amazed that the i notation is simply a 32bit number van can be used like that. Or even http://0xd1d8e6f0

For example, even if you do vind to localhost, anyone on your system can access your service. Let’s say an electron is running on port 5555. A guest user on your system can just access the electron app. If this app happens to be vscode, you now have full access.

It’s just plain stupid. You basically nuked multi user security. Better run dos then

Re: Userspace FUSE for macOS

#73

Post by jbverschoor »

lxgr wrote: post #54
jbverschoor wrote: post #28

Why does everybody use tcp ports instead of file sockets for local communication?

Does the built-in macOS SMB client support mounting resources via file socket?

The bsd mount_nfs code uses AF_INET. Which makes sense. But I got triggered by the fact that is yet another app listening to ip

Re: Userspace FUSE for macOS

#74

Post by skissane »

searealist wrote: post #32
jbverschoor wrote: post #28

Why does everybody use tcp ports instead of file sockets for local communication?

Unix domain sockets have a severe limitation that the path must be a maximum 108 characters.

Is anybody trying to lift that limitation? It seems like an obvious target for kernel devs to tackle.

If Linux and *BSD did it (especially if they adopted a mutually compatible implementation), the POSIX standardisation team (Austin Group) would likely be interested in adding it to POSIX, and Windows/macOS/AIX/etc will likely follow their example sooner or later.

Re: Userspace FUSE for macOS

#75

Post by skissane »

What advantages does NFSv4 have over SMB/CIFS for this use case?

I have had the same idea myself before, but with a more cross-platform scope (Linux and Windows too, not just macOS). Whatever it flaws, SMB/CIFS has the advantage of being supported out-of-the-box on more platforms than NFSv4 is.

Re: Userspace FUSE for macOS

#76

Post by skissane »

justsomeadvice0 wrote: post #58
EdSchouten wrote: post #5

What a coincidence! For a project that I maintain (Buildbarn, a distributed build cluster for Bazel) I recently generalized all of the FUSE code I had into a generic VFS that can both be exposed over FUSE and NFSv4. The intent was the same: to provide a better out of the box experience on macOS. Here's a design doc I wrote on that change. Slight warning that it's written with some Buildbarn knowledge in mind. https:/…

You might look at webdav instead, which has actual existing library implementations (unlike NFSv4), supports user/pass auth (in some cases you don't want wide-open services on loopback) and is based on HTTP; that would make the whole thing easier. Various projects offer a webdav combat layer, see cryptomator for one example: https://docs.cryptomator.org/en/latest/desktop/vault-mountin... I went down the NFS road long…

I remember, around 10 years ago, mucking around with WebDAV, and discovering many WebDAV clients were extremely crapulent. Especially on Windows.

Maybe, some years later, Windows' WebDAV client has improved. And I can't remember whether macOS WebDAV was better or not.

Re: Userspace FUSE for macOS

#77

Post by skissane »

rgovostes wrote: post #4

Unfortunately, like macFUSE, this is not really open source. The license appears to be BSD-like for non-commercial use only. Also like macFUSE, the project uses GitHub but the source code is not available. https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt

The developer says they will release source code soon – https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... – although keeping the restrictive license.

Apple is introducing user-space file system technology in macOS – LiveFS/UserFS/com.apple.filesystems.lifs – some of the infrastructure turned up in Monterey, in Ventura it is actually being used for mounting FAT/exFAT filesystems.

It looks like for now Apple is keeping the API Apple-internal only (although I haven't looked at the Ventura SDK, so I could be wrong about that). But if Apple made the API public, it could be the death-knell of all these commercial FUSE-alternatives for macOS offerings. (Even if Apple's API isn't FUSE-compatible, if it is close enough, someone could easily open-source a translation layer – likely to be a lot simpler than bridging FUSE to an NFS server.)

Re: Userspace FUSE for macOS

#78

Post by chrismonsanto »

searealist wrote: post #32
jbverschoor wrote: post #28

Why does everybody use tcp ports instead of file sockets for local communication?

Unix domain sockets have a severe limitation that the path must be a maximum 108 characters.

This limitation only applies to the file name, as you can chdir to the directory before bind/connect. Unfortunate but not a deal breaker

Re: Userspace FUSE for macOS

#79

Post by trasz »

alerighi wrote: post #40
tambourine_man wrote: post #12

macOS really needs a decent FUSE implementation. That and some sort of container story. Such a shame that it's not really open source. The idea of using NFSv4 is awesome though.

Awesome, to me it seems terrible, and something that can break anytime. You have two layers of translation, the actual FUSE filesystem implementation that uses the FUSE API to communicate with something that emulates a FUSE API in userspace to then talk via NFS to the kernel. NFS is broken in a lot of ways, especially with file locking, that could result in deadlocks. Really FUSE should be implemented in the kernel i…

NFS4 is broken in fewer ways FUSE is, and it has the advantage of being standardised and implemented by everything. The natural way forward would be to get rid of FUSE in this stack, not NFS4.

Re: Userspace FUSE for macOS

#80

Post by trasz »

mdaniel wrote: post #63
clhodapp wrote: post #22

Earlier quoted context omitted.

You're assuming that everyone's "prod" is a Linux server. I would say that MacOS needs containers for developing Darwin software.

Yes, I think that's a perfectly reasonable assumption given that (AFAIK) the only current "containerization" (as GP used that word) strategy is on Linux. BSD has jails and Solaris has something similar, but as far as "fire this thing up with its own pid, network, and fs namespacing, and allow me to constrain it easily" that's just Linux. I guess put another way: you run Darwin in production? As for the latter, macOS…

>BSD has jails and Solaris has something similar, but as far as "fire this thing up with its own pid, network, and fs namespacing, and allow me to constrain it easily" that's just Linux.

Nope, you get the same thing with jails, just easier. Jails weren't developed by a company living off selling support for it, you know :-)

Post reply on HN