Live data from Hacker News

A Base Filesystem Project for macOS

kext.io

31–40 of 45 posts

Re: A Base Filesystem Project for macOS

#31
post #11
post #4

Just yesterday I was thinking how all of the platforms are still using vfat as a go between. There really should be a new FS "for them all"

All attempts at such will fail. vfat won because it works in Windows without additional drivers. Anything you come up with to replace it will also have to work in Windows without additional drivers. It will also have have a workable implementation in what is essentially equivalent to the public domain, and be simple enough to process that hardware manufacturers can read it with a microcontroller. I would love to see…

Already exists, UDF. Built-in support on macOS, Windows, Linux.

Another option is NTFS, the one limitation is by default it is read only on macOs.

Re: A Base Filesystem Project for macOS

#32
post #22
post #14

Earlier quoted context omitted.

vfat only won in the sense that if you're forced to use windows you still have to use vfat. In every other context there is a better option. I haven't needed to move files to a windows box in 15 years so—to me—it's a massive surprise anyone still uses it at all. Just don't use USB keys; they're terrible security-wise and you're forced to use technology built for your grandmother.

You're an outlier. I live in an environment where I need to move files between several builds of Windows, Linux and macOS - and often where there is no network access because of security policy (misguided policy perhaps). Thumb Drives are the only way to function.

Can you say anything more about the environment? I'm curious.

Re: A Base Filesystem Project for macOS

#33
post #22

Earlier quoted context omitted.

You're an outlier. I live in an environment where I need to move files between several builds of Windows, Linux and macOS - and often where there is no network access because of security policy (misguided policy perhaps). Thumb Drives are the only way to function.

Can you say anything more about the environment? I'm curious.

Smells like the IT department of BigCo or public agencies to me. Been there, seen that. Literally terabytes of Debian binary packages transferred by hand with USB keys and disks between the dev network and the secure network.

Oh, and the USB serial numbers of the keys had to be whitelisted on the secure network. What a fun that one was. They didn't even stop doing that after I showed them that I could modify the firmware of some of the sticks using software from some obscure Russian site and thus bypass the control...

(Does anyone know by chance how that website is/was named? All I remember is that it held hundreds of manufacturer tools for all kinds of USB stick controllers/flash chips)

Re: A Base Filesystem Project for macOS

#34
post #26
post #21

Earlier quoted context omitted.

My proposal: xkcd3, works as xkcd3:927 AND xkcd3://927 And that's why Linux desktop is going nowhere.

hi, what about xkcd4:ⅽⅿⅹⅹⅶⅹ or xkcd5:٩٢٧ (note: may not appear in correct reading order due to technical limitations)

I propose a browser powered by deep machine learning that lets you just write 927 and automatically figures out that it refers to an XKCD by inferring the context from looking at the content on the rest of the page.

Re: A Base Filesystem Project for macOS

#36
post #4

Just yesterday I was thinking how all of the platforms are still using vfat as a go between. There really should be a new FS "for them all"

via fuse, ntfs is pretty broadly available... iirc there was a recent post about efforts to bring a fuse alternative for windows in (which should bring ext3 and btrfs)... I tend to just use ntfs for most of my external storage and cifs for network storage only because it's easier to get on my non-windows systems than nfs and ext3 are to get working on windows... ymmv though.

> about efforts to bring a fuse alternative for windows in

You mean dokany? 'cause that one is one quite stable project.

Re: A Base Filesystem Project for macOS

#37
post #11

Earlier quoted context omitted.

All attempts at such will fail. vfat won because it works in Windows without additional drivers. Anything you come up with to replace it will also have to work in Windows without additional drivers. It will also have have a workable implementation in what is essentially equivalent to the public domain, and be simple enough to process that hardware manufacturers can read it with a microcontroller. I would love to see…

as mentioned above, ntfs works, but you'll need a driver for linux and macOS, which isn't too bad, and easier than getting unix file systems on windows.

There's also no fsck for NTFS on linux, so in the event of a power failure (or out-of-battery), you're stuck with a useless FS until you visit someplace with windows/osx machines.

Re: A Base Filesystem Project for macOS

#38
post #4

Just yesterday I was thinking how all of the platforms are still using vfat as a go between. There really should be a new FS "for them all"

I think today it's exFat instead of vfat. That seems to be supported by a lot of phones and devices for large storage.

Far from being "simple to implement", it's patent encumbered, making implementations for many OSs highly unlikely.

Re: A Base Filesystem Project for macOS

#39
post #11

Earlier quoted context omitted.

All attempts at such will fail. vfat won because it works in Windows without additional drivers. Anything you come up with to replace it will also have to work in Windows without additional drivers. It will also have have a workable implementation in what is essentially equivalent to the public domain, and be simple enough to process that hardware manufacturers can read it with a microcontroller. I would love to see…

> vfat won because it works in Windows without additional drivers. I would not understate that it is also very simple to write a driver for. The reasons for this have high overlap with the fact that the ondisk structure is crap. But it does mean that many people were able to write drivers.

I wrote a driver for it on an 8-bit chip that had 16kB of code space and 2kB of RAM. It was ugly, and it could only hold two sectors at a time in memory (if I recall, one from the FAT and one from the current file). Despite it being ugly... it worked! Best of luck getting pretty much any other standard filesystem running in that.

Re: A Base Filesystem Project for macOS

#40

Earlier quoted context omitted.

as mentioned above, ntfs works, but you'll need a driver for linux and macOS, which isn't too bad, and easier than getting unix file systems on windows.

There's also no fsck for NTFS on linux, so in the event of a power failure (or out-of-battery), you're stuck with a useless FS until you visit someplace with windows/osx machines.

You can run ntfsfix, a part of the ntfs-3g suite, to fix fs errors.
Post reply on HN