I'm a bit puzzled as to how split files with name standardization is an "extension." It seems to me that SEGGER is simply proposing a de facto file naming convention, and offering a few free tools (including a few abstraction drivers) to encourage adoption. Can somebody fill me in, here- where's the value in what SEGGER is proposing, as opposed to what the entire IT community has already been doing for decades?
BigFAT – Backward compatible FAT extension for unlimited file size
11–20 of 109 posts
Re: BigFAT – Backward compatible FAT extension for unlimited file size
#12I love seeing this, don't get me wrong. I am just curious is there are any real world applications for this?
Re: BigFAT – Backward compatible FAT extension for unlimited file size
#13Awesome concept, especially for academia ... but is there a value proposition? I love seeing this, don't get me wrong. I am just curious is there are any real world applications for this?
Re: BigFAT – Backward compatible FAT extension for unlimited file size
#14So, this is a bit of a cultural/perception gap between FOSS developers and standards bodies. Most standards bodies have a patent policy of "as long as all the standards-essential patents are licensable for a uniform fee, we're good". Convincing patent holders to not extract royalties from their patents for the sake of easing the lives of FOSS implementers is much, much harder[0].
Microsoft isn't even the only SEP holder for SD, and the standard makes no attempt at being a royalty-free standard. In fact, early SD standards were NDA'd[1] and prohibited FOSS implementation at all.
[0] In fact, so hard that the EU has a conspiracy theory that Google/AOM bullied a patent holder into doing this
[1] Remember, SD cards were basically MMC with primitive DRM
Re: BigFAT – Backward compatible FAT extension for unlimited file size
#15Awesome concept, especially for academia ... but is there a value proposition? I love seeing this, don't get me wrong. I am just curious is there are any real world applications for this?
This would be extremely niche but would have its audience. Heck, I wouldn't be surprised if HN readers adopted it just to taste the thrill of unlimited and obscene power.
Re: BigFAT – Backward compatible FAT extension for unlimited file size
#16Awesome concept, especially for academia ... but is there a value proposition? I love seeing this, don't get me wrong. I am just curious is there are any real world applications for this?
It would be great to have a non-patent-encumbered simple file format that's supported everywhere. The fact that this is based on FAT32 might help adoption, everyone's computers can already at least read a BigFAT drive, and BigFAT support could be added at the application level for systems which don't support it at an OS level.
Re: BigFAT – Backward compatible FAT extension for unlimited file size
#17I like the idea. Making it backwards compatible with FAT means that, in principle, regular FAT filesystem implementations could be transparently changed to support big fat files (hehe) transparently. However, reading the spec, it doesn't look fully backwards compatible? It seems like there are file structures which are possible to represent in FAT which aren't possible to represent in BigFAT. In FAT, I could have a 4…
ReactOS is using btrfs, which has so many useful options that FAT will never see (zstd, xxhash, flash-aware options, snapshots, send/receive, etc.). This is positioned both for Linux and Windows.
Microsoft itself restrains ReFS to enterprise use, and btrfs offers so much more functionality. We should stop using a file system from the '80s.
Re: BigFAT – Backward compatible FAT extension for unlimited file size
#18Earlier quoted context omitted.
It would be great to have a non-patent-encumbered simple file format that's supported everywhere. The fact that this is based on FAT32 might help adoption, everyone's computers can already at least read a BigFAT drive, and BigFAT support could be added at the application level for systems which don't support it at an OS level.
Are the filesystem used on bsd and linux distros patent encumbered? Isn't UFS2 simple enough?
Re: BigFAT – Backward compatible FAT extension for unlimited file size
#19I like the idea. Making it backwards compatible with FAT means that, in principle, regular FAT filesystem implementations could be transparently changed to support big fat files (hehe) transparently. However, reading the spec, it doesn't look fully backwards compatible? It seems like there are file structures which are possible to represent in FAT which aren't possible to represent in BigFAT. In FAT, I could have a 4…
There are so many good filesystems out there. Is it really necessary to keep dragging FAT along? ReactOS is using btrfs, which has so many useful options that FAT will never see (zstd, xxhash, flash-aware options, snapshots, send/receive, etc.). This is positioned both for Linux and Windows. Microsoft itself restrains ReFS to enterprise use, and btrfs offers so much more functionality. We should stop using a file sys…
Re: BigFAT – Backward compatible FAT extension for unlimited file size
#20Earlier quoted context omitted.
It would be great to have a non-patent-encumbered simple file format that's supported everywhere. The fact that this is based on FAT32 might help adoption, everyone's computers can already at least read a BigFAT drive, and BigFAT support could be added at the application level for systems which don't support it at an OS level.
Are the filesystem used on bsd and linux distros patent encumbered? Isn't UFS2 simple enough?