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

21–30 of 137 posts

Re: Userspace FUSE for macOS

#21

Post by tambourine_man »

mdaniel wrote: post #16
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.

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

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.

Re: Userspace FUSE for macOS

#22

Post by clhodapp »

mdaniel wrote: post #16
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.

> 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.

Re: Userspace FUSE for macOS

#23

Post by orangea »

lillecarl wrote: post #20
orangea wrote: post #19

Why not use the file provider API? https://developer.apple.com/documentation/fileprovider

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.

Re: Userspace FUSE for macOS

#24

Post by duskwuff »

tambourine_man wrote: post #21
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…

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

Re: Userspace FUSE for macOS

#25

Post by mathiasgredal »

orangea wrote: post #19

Why not use the file provider API? https://developer.apple.com/documentation/fileprovider

I found the api incredibly hard to use as someone who hasn't used swift or macOS API's before. Because of the way some of the code runs as a separate plugin from the main app, you can't really use traditional logging as a debug tool. There is also a lot of split state to be handled. You have to provide sync anchors and diffed tree updates to change the folder contents, which just aren't available with most backends.

I started on a program to mount a website resource directory on your computer using this api, but I gave up due to the restrictions of the api: https://github.com/mathiasgredal/Itslearning

Re: Userspace FUSE for macOS

#26

Post by concerned_ctzn »

keepquestioning wrote: post #7
freebeer2 wrote: post #2

A new project aims to deliver libfuse for mac without using kernel extensions.

Could this be done using DriverKit

The author here. DriverKit is really a no-go. A while back I was asked to do a project based on DriverKit, it took me nowhere because of countless bugs and semi-implemented features, worse yet, it caused system crashes (and it was supposed to be stable).

Re: Userspace FUSE for macOS

#27

Post by jbverschoor »

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

or just use asdf

Re: Userspace FUSE for macOS

#30

Post by inetknght »

jbverschoor wrote: post #28

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

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

In my experience it's because Windows and mac developers aren't aware of local file sockets. Windows API, in particular, doesn't have a similar concept if I recall.

Post reply on HN