4 ms·

What prevents Apple from just integrating MacFUSE(or a reimplementation) into the their kernel, and then shipping it with the next release?

yjftsjthsd-h 3y ago
I'd be shocked if there was any technical reason they couldn't; if they haven't, they either don't care or actively don't want to for some reason. (But yes, I think they could and a lot of people would be very happy if they did)
pjmlp 3y ago
Basically doesn't fit their roadmap.
dagmx 3y ago
Isn’t Fuse itself LGPL? Thats perhaps one reason since copyleft licenses aren’t favourable from their view. I would really love any equivalent API though as dealing with Perforce is a pain in the butt sometimes, and what Microsoft have done with the Prrforce Virtual File system is amazing.
- arthur2e5 3y ago
  Macfuse itself has been closed source for a long time. Whether their EULA is compatible with the LGPL though, I don’t know. (Also, the old question: are APIs copyrightable?)
  - dagmx 3y ago
    But do they bundle libfuse as a dylib? If they do, they’re probably in the right. And API copyright aside, how would one prove it’s only API compatible and not using the implementation as well without also open sourcing their implementation? It would almost be better to be similar but not the same. Then everyone else can just do subtle ifdef changes to their fuse code.
MyelinatedT 3y ago
If they ever do this, it’ll probably take the form of a proprietary userspace FS interface that will only work through Finder and will require the binary to be downloaded from the Mac App Store or otherwise signed by Apple. Every dev that wants to use it will have to pay Apple for the privilege. But maybe I’m just being cynical.
lxgr 3y ago
They already have something like this, it's just not a public API and only used for their own FAT and NTFS implementations: https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-file-systems-on-macos-ventura/ https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-f...

yjftsjthsd-h 3y ago

I'd be shocked if there was any technical reason they couldn't; if they haven't, they either don't care or actively don't want to for some reason. (But yes, I think they could and a lot of people would be very happy if they did)

pjmlp 3y ago

Basically doesn't fit their roadmap.

dagmx 3y ago

Isn’t Fuse itself LGPL? Thats perhaps one reason since copyleft licenses aren’t favourable from their view. I would really love any equivalent API though as dealing with Perforce is a pain in the butt sometimes, and what Microsoft have done with the Prrforce Virtual File system is amazing.

arthur2e5 3y ago
Macfuse itself has been closed source for a long time. Whether their EULA is compatible with the LGPL though, I don’t know. (Also, the old question: are APIs copyrightable?)
- dagmx 3y ago
  But do they bundle libfuse as a dylib? If they do, they’re probably in the right. And API copyright aside, how would one prove it’s only API compatible and not using the implementation as well without also open sourcing their implementation? It would almost be better to be similar but not the same. Then everyone else can just do subtle ifdef changes to their fuse code.

MyelinatedT 3y ago

If they ever do this, it’ll probably take the form of a proprietary userspace FS interface that will only work through Finder and will require the binary to be downloaded from the Mac App Store or otherwise signed by Apple. Every dev that wants to use it will have to pay Apple for the privilege. But maybe I’m just being cynical.

lxgr 3y ago

They already have something like this, it's just not a public API and only used for their own FAT and NTFS implementations: https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-file-systems-on-macos-ventura/ https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-f...