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

131–137 of 137 posts

Re: Userspace FUSE for macOS

#131

Post by Cyberdog »

tambourine_man wrote: post #123
Cyberdog wrote: post #59

Earlier quoted context omitted.

I'm not sure of the specifics with Homebrew, but with MacPorts, I have both PHP 7.4 and 8.1 running via FPM and serving sites rather trivially. The basics: Install both php74-fpm and php81-fpm, configure the former to put its socket at /var/run/php74-fpm.sock and the latter at /var/run/php81-fpm.sock, configure nginx's domain-specific config files to look for the FastCGI socket that the respective path, use MacPorts…

I edit Apache’s config files and reload it every time, but I’m not pleased with that solution.

Is there not a way in Apache to specify a different path for the FastCGI socket based on the domain name? It's been a long time since I've used Apache but I'd be surprised if the functionality wasn't somewhere in its inscrutable config file syntax.

Re: Userspace FUSE for macOS

#132

Post by vaxman »

This is a Bad idea.

Do you expect Apple has any consideration that things like this are happening inside the usermode processes when its System suspends and compresses or decompresses their memory of or throttles them by flinging them back and forth to different classes of CPU cores or analyzes them to look for other efficiencies that they don’t talk about publicly (network, thermal, sandbox, etc). If Apple wants FUSE, it will build a carve-out (in the form of a framework) like it did for virtualization. If you still want to use FUSE, maybe try System76’s Pop!_OS or find The [Apple] Way to accomplish your client’s goal.

https://youtu.be/1LHuEvw56F8

Re: Userspace FUSE for macOS

#133

Post by zbentley »

pabs3 wrote: post #112
searealist wrote: post #100

Earlier quoted context omitted.

Care to justify your advice?

They are ephemeral, they hold no data after being closed and backups of them aren't useful. Only the name is needed, therefore a tmpfs is the place to store them.

The name of the socket file/the fact that it exists contains data.

As a result, it's useful to keep them in non-tmpfs paths that can survive a reboot. That way, very simple programs can use them as sort of a config file: `$XDG_HOME/myprogram/do_xyz.sock`.

Additionally, persistent sockets created once at program install time can help coordinate multiple launches of whatever uses them (e.g. by having servers flock(2) the socket or fight over binding to it as a mutex). For programs whose "server" component isn't managed by a service manager, but can instead be launched many times in response to some user action, that can simplify things.

Re: Userspace FUSE for macOS

#134

Post by zbentley »

jbverschoor wrote: post #72
userbinator wrote: post #65

Earlier quoted context omitted.

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 s…

In practice these problems occur, but more rarely than you're implying.

First, many of the systems that local-use-only-but-served-via-TCP-on-localhost apps use are not multi user. VS Code is a good example; I'd hazard that the vast majority of installs thereof are on systems that don't have simultaneous users logged in.

Second, many localhost-tcp apps do use authentication of a sort; this is simple to set up via a secret that is pre-shared at application installation time.

Third, it's easily possible to use ip[tables] to restrict loopback traffic based on conditions that include user ID or group ID. I'm not sure how many people take advantage of this capability, since doing so reliably would probably imply the "server" component having root so it could impose firewally restrictions on loopback users at startup time.

Re: Userspace FUSE for macOS

#135

Post by alerighi »

trasz wrote: post #79
alerighi wrote: post #40

Earlier quoted context omitted.

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.

Well I don't see how FUSE is broken, while NFS surely is (it happened to me that I had processes that were in a state that was impossible to terminate without rebooting - this was because they did set locks in the NFS filesystem that they were never released, thus not allowing the processes PID to terminate and thus generating a slow resource leak in the kernel!)

Anyway, FUSE is more efficient, since the application directly talks to the kernel, without passing trough the TCP/IP stack and the NFS driver. It cannot be possibly implemented more efficiently without implementing the FS as a proper kernel module.

Also NFS introduces a security problem: authentication is tricky to implement, and I don't think it's used in this application: that allows any user on the computer to access, via the NFS API trough an userspace implementation the filesystem, bypassing any permission of the filesystem itself.

Finally NFS cannot support (as far as I know) all the features that are possible with a FUSE filesystem. And since it's based on a network protocol (meaning client and server may be on different machines with a non reliable network connecting them) something will probably never be supported/work reliably (for example inotify).

Re: Userspace FUSE for macOS

#136

Post by justsomeadvice0 »

EdSchouten wrote: post #106
justsomeadvice0 wrote: post #58

Earlier quoted context omitted.

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…

For Buildbarn I need to provide a writable file system that acts in a POSIX compliant way. I'm not convinced WebDAV could provide that.

Fair point, agreed I doubt mount_webdav ends up posix compliant.

Re: Userspace FUSE for macOS

#137

Post by tambourine_man »

Cyberdog wrote: post #131
tambourine_man wrote: post #123

Earlier quoted context omitted.

I edit Apache’s config files and reload it every time, but I’m not pleased with that solution.

Is there not a way in Apache to specify a different path for the FastCGI socket based on the domain name? It's been a long time since I've used Apache but I'd be surprised if the functionality wasn't somewhere in its inscrutable config file syntax.

That’s a really cool idea, never though of that. I’ll investigate, thanks! Sorry for the late reply.
Post reply on HN