131–140 of 211 posts
Earlier quoted context omitted.
Great comment. Is there anywhere I can read about how it worked and what it was used for before it became a "veriform appendix"? It seems really interesting.
Inside Macintosh Vol I, II, II: http://www.weihenstephan.org/~michaste/pagetable/mac/Inside_...
Interesting that it is HFS+ getting accused of being crazy, rather than the (blatantly deficient) POSIX-style tools!
> Interesting that it is HFS+ getting accused of being crazy, rather than the (blatantly deficient) POSIX-style tools! That's UNIX parochialism for you.
> Applications — even basic filesystem tools — aren't aware of the additional content. How do you deal with a file with two sets of data? I'm sure there's an Apple-y reason for the existence of this feature, but I can't imagine what it might be. G.K. Chesterton on the matter: In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be…
I prefer the less verbose version: "Don't just do something. Stand there." --Marvin Minsky
I know this feeling well but I don't really get how it causes some people to think "I'll write a blog post complaining about this" rather than "I'll do a quick search for this and find out the answer, which might be nuanced, historically contingent, and/or revelatory."
TLDR: Mac filesystems have resource forks. I guess the author has not used Macs too much, as they have been around since the 1980's.
TLDR: all standard applications for working with files are unaware of resource forks. This is confusing, and hurts new computer users. #consideredharmful
Earlier quoted context omitted.
It seems you are knowledgeable on the topic, why not make your criticism a bit more constructive? Why are "multiple data forks/stream" needed and what are they used for? (I don't know very much about file systems)
Basically, the "resource fork" in MacOS was... well, Wikipedia actually puts it pretty well: "a section of a file used to store structured data along with the unstructured data stored within the data fork." It was frequently used to store things like images and icons (and fonts), but could also be used to store metadata. Think of it as the equivalent of having a document database -- a key/value store -- alongside a f…
I never got to use BeOS, and Haiku seems to be stuck perpetually in the "almost there"-stage (Haven't been paying attention in the last couple of years, though). But this helps me understand why people worked and work so doggedly on reviving BeOS.
Earlier quoted context omitted.
ext4 deprecation hangs in the air and it's not very good filesystem, btrfs is probably the future and it's slowly becoming production ready.
yah absolutely ext4 has progressively had its' performance reduced because what made it faster than ext3 created a lot of corner cases that make it far less reliable, and Btrfs is at least a fresh design, but doesn't seem to be particularly ready and is not even proven as a reliable design. It's good that we have more than one filesystem. HFS+ functionally works well for a Mac because the Mac is designed around it, b…
Wouldn't it be cool if Apple just picked up a standard file system from somewhere else? Ext4 for example.
Earlier quoted context omitted.
You wouldn't put the entire content of a file in an extended attribute, would you?
On Mac Classic, if you wanted to ship a custom font with your application, you'd put it in the Resource fork in a resource of "FONT" type. So why wouldn't a stand-alone font file consist of a Resource fork with a single resource of "FONT" type? Otherwise, the OS engineers have to develop two entirely different ways of reading in font data. Why duplicate the effort? The system made perfect sense, both then and now. It…