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

61–70 of 137 posts

Re: Userspace FUSE for macOS

#61

Post by TimTheTinker »

mdaniel wrote: post #6
concerned_ctzn wrote: post #3

https://github.com/macos-fuse-t/fuse-t

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 statutory or implied warranties - i.e. they left out some important exclusions that could be brought to bear if a plaintiff successfully construed the license as a contract.

(IANAL, but I've read a lot about software licenses over the years and have dealt with a legal challenge related to dual commercial/OSS licensing)

Re: Userspace FUSE for macOS

#62

Post by mdaniel »

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.

While digging up a link for a separate comment, I found (https://macoscontainers.org/) which points to: https://github.com/containerd/containerd/discussions/5525

Re: Userspace FUSE for macOS

#63

Post by mdaniel »

clhodapp wrote: post #22
mdaniel wrote: post #16

Earlier quoted context omitted.

> That and some sort of container story. While off-topic for this thread, I don't think that's going to do what you expect. If you snapped your fingers and XNU suddenly had cgroups and other namespace trickery required to make containers operate, you'd still have the grave problem of "containers are not virtual machines" and thus an XNU container would only run Darwin binaries, so you're back to the old days of "run…

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 actually does have what they call Containers (https://developer.apple.com/library/archive/documentation/Se...) but as best I can tell such a thing requires opt-in from the app, which kind of defeats the purpose of running untrusted software IMHO. I actually only learned about that Containers stuff from trying to find where in the hell 1Password 8 stores its actual sqlite file: `$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data/1password.sqlite`

Re: Userspace FUSE for macOS

#64

Post by tech234a »

mdaniel wrote: post #8

I don't know what's going on with the google.com/url encoding of the links on the submitted article Also, one will want to be aware of the currently unsupported features https://github.com/macos-fuse-t/fuse-t/wiki#unsupported-feat... > since the submitted article appears to be aspirational

The page appears to be hosted on the new Google Sites.

Re: Userspace FUSE for macOS

#66

Post by sroussey »

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…

Thanks for this. I have a library that uses 1Password files and have not updated for v8.

Re: Userspace FUSE for macOS

#67

Post by boulos »

EdSchouten wrote: post #17
boulos wrote: post #14

Earlier quoted context omitted.

Nit: NFSv3 is stateless, V4 isn't (sessionid and clientid permit stateful handling of locks and shares). I would assume this person is just doing an in-memory "NFS server" that would keep all of that state around. So it's more like a FUSE-compatible layer that speaks NFSv4 as a "front end" (since NFS clients are better than "ha ha, surprise! This FUSE backend is networked and can fail on weird ways"). I'm not sure ho…

With it being stateless, I was referring to just the part where I wanted to point out the difference: file handles are stateless, while FUSE's equivalent (nodeids) are stateful. Regardless of whether it's an in-memory or persistent solution, the problem remains: fuse-t has little choice but to leak resources of the underlying FUSE file system, as there is no valid point in time in which you can issue FORGET operation…

> macOS implements NFSv4.0, while SEQUENCE is part of NFSv4.1 and later.

Whoa. That's a real mistake. v4.0 is widely considered a "oops, we shouldn't have released this". TIL!

Re: Userspace FUSE for macOS

#68

Post by chrisseaton »

duskwuff wrote: post #24
tambourine_man wrote: post #21

Earlier quoted context omitted.

Yeah, but easily switching between specific version of PHP, MySQL, Node.js, etc, without messing with /usr/local/bin and brew while having full speed disk access goes a long way. I could probably get by with the chroot support that macOS has, but I never manage to find the motivation.

You can install multiple versions of PHP and Node alongside each other just fine using Homebrew: brew install php@7.2 php@7.3 php@7.4 php@8.0 php@8.1 # and soon php@8.2 brew install node@18 node@16 node@14 node@12 node@10

Most people don't want to install and uninstall software at the system-level like that. They'd rather have nicely isolated disposable containers for individual projects.

Re: Userspace FUSE for macOS

#69

Post by pstuart »

klabb3 wrote: post #60
pstuart wrote: post #29

Earlier quoted context omitted.

2 guesses: ignorance, and an assumption that using tcp allows for seamless transition to another host.

I guess I'm ignorant then! When I looked up domain sockets and so on it turned out to be different APIs for different OS:s, and it's significantly nicer to rely on a single API surface from the std lib. Maybe it's a habit thing as well, but to me pipes are more esoteric and harder to find docs about than network sockets.

> I guess I'm ignorant then!

We all are in our own ways ;-). I pulled that comment out of my ass so I'm ok with being corrected as appropriate.

Re: Userspace FUSE for macOS

#70

Post by jbverschoor »

klabb3 wrote: post #60
pstuart wrote: post #29

Earlier quoted context omitted.

2 guesses: ignorance, and an assumption that using tcp allows for seamless transition to another host.

I guess I'm ignorant then! When I looked up domain sockets and so on it turned out to be different APIs for different OS:s, and it's significantly nicer to rely on a single API surface from the std lib. Maybe it's a habit thing as well, but to me pipes are more esoteric and harder to find docs about than network sockets.

But they are not (named) pipes, it’s the same api. Just speak http or whatever over the socket. Afaik, windows also seems to support it these days
Post reply on HN