41–50 of 137 posts
Earlier quoted context omitted.
Unix domain sockets have a severe limitation that the path must be a maximum 108 characters.
That’s plenty for most applications, no? /var/run/*.sock isn’t that many characters.
Why not use the file provider API? https://developer.apple.com/documentation/fileprovider
The design was obviously tailored for providers that implement real disk files, like Dropbox and Apple's own iCloud Drive.
Btw, Apple also ships with an undocumented 9P implementation. It seems to be used for mounting the host filesystem in virtualized guests. It is unclear if it can be made to work over a normal (non-PCI) transport like TCP.
Earlier quoted context omitted.
Because your software was written against FUSE and you don't wanna spend time rewriting it to accommodate Apple users.
I meant why not make a project like this that emulates the FUSE API, but use the file provider API to present the file system to the OS instead of NFS. It would have the advantage that it would be better integrated with the OS, for example you can display upload progress indicators on files in Finder. Maybe that can also be done with NFS though, I don't know.
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
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…
FUSE really demonstrates the unreasonable effectiveness of file systems as an interface.
Earlier quoted context omitted.
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
or just use asdf