[thought_alarm]

It's amazing how garbage like this always rockets to the top of HN. This guy doesn't know anything about file systems or about the operating system he's using. But he sounds confident, so that's evidently good enough for a lot of people.

If you think it's crazy that a file system supports multiple data forks/steams, then you don't know very much about file systems.

If you think it's crazy that an operating system maintains backward compatibility with an older system, then you don't know very much about operating systems.

If you arrogantly make these pronouncements on your website then you look like a complete idiot.

[Profan]

People don't know what they don't know. Talking down to people who think something is strange for being the way it is, instead of explaining to them why it is, is so counterproductive and serves no purpose. Everyone has things they don't know, just provide an explanation instead of an arrogant comment.

He even says "I'm sure there's an Apple-y reason for the existence of this feature, but I can't imagine what it might be." That's literally a "i'm not sure why this is" right there!

[saidajigumi]

This isn't about what the author does/doesn't know. The author managed to figure out that this was about resource forks, meaning that clearly they'd done some footwork and had found the right thread of information to follow.

But GP's point gets to how the author handled that new knowledge: post an essay of cranky, self-assured tone to their website instead of following that thread to understand how and why OS X resource forks came to be. I.e. they followed the path of "anything I don't already know must be wrong":

I'm sure there's an Apple-y reason for the existence of this feature, but I can't imagine what it might be.

It's hard not to bash this kind of rhetorical mess. "I took the time to research everything up to here, then EPIC FLOUNCE!"

If you're going to write an article critical of HFS+, perhaps making an argument for a successor, great! It's a topic I'll get wholeheartedly behind. But this article is just lazy bitching on the internet, which certainly doesn't deserve to be voted up.

[btilly]

Well, both points of view have a point.

The central idea of Unix is that everything is a file. Files are just streams of bytes on disk. Most happen to be text. Text is just streams of lines. And then you write a bunch of simple tools that handle files, bytes, and lines, and they will combine really well for more complex tasks.

However this was (and in many corners still is) a radical idea. The natural tendency in virtually every other system, from the Macintosh to IBM mainframes, was to store data in various structured records. Whether we're talking resource forks or records, you always, always, always add structure of various kinds. The idea of just scanning through bytes to find, say, the end of a record is shockingly inefficient.

So we have the point of the article. HFS+ breaks Unix. If you don't see that, then you don't actually understand Unix. The filesystem ignores one of the founding central concepts, with the result that the entire Unix toolkit and way of thinking about the world doesn't work. Standard utilities, scripts, etc don't know that resource forks exist, and will do the wrong thing with them. If you walk into OS X and are told, "It's Unix under the hood", well that is a lie. It really isn't. You can work within it and only do Unix things and it will work, but as soon as you access things from elsewhere in the Apple ecosystem, things break in ways that they wouldn't in, say, Linux.

But we also have your point of view. There are very good reasons that HFS+ works the way it does. And it is integrated into the UI in ways that date back decades. And THIS is true. OS X was an attempt to put a Macintosh UI on a fork of Unix. And preserving central concepts of Unix really were not as important as making the UI work right. With the same features. With data being reasonably easy to port between the two systems, and programs not unnecessarily different.

Both points of view are valid. Which one matters depends on what you're trying to do. Furthermore it is natural, not stupid, that a person who has just had a major plank pulled out from under their way of understanding the world tends to have a strong emotional response.

"OMG, you broke everything! The tools that I rely on don't work and I have no idea what else is broken!" This is an extremely common response. This is one of the reasons why it can be hard for programmers to switch languages and environments.

As it happens, I personally understand both points of view. I have over 20 years of experience with both Macs and Unix. This is typed on an Apple laptop. But fundamentally I agree with the article. Apple broke Unix. I recognize that there is no solution at this point, and I mostly confine myself to living within the Unixy parts of the system. But HFS+ got it wrong and is not well integrated with the command line. I mean look at this. If you have myfile you can look at myfile. Then ls myfile/..namedfork and get an error. Then ls $file/..namedfork/rsrc and see more stuff??? And I can only know to do this if I know it is there to be seen???

That's just broken.

[JupiterMoon]

I was under the understanding that Apple never originally really intended people to use the Unix side of OSX and that the whole command line standard Unix utilities became commonly used in spite of Apple's design. I could be wrong.

[btilly]

I have no idea if there was a conscious choice either way. However the goal was certainly, "Our cooperative multi-tasking system where any bad application takes out the operating system no longer cuts it, migrate to a preemptive one." And building on Unix was the shortest path there.

There were many disconnects between the two systems. See https://www.usenix.org/legacy/event/usenix2000/invitedtalks/... for some of them.

[rconti]

I don't read the blogpost the same way. I read it as confident condescension.

[andrewmcwatters]

Searching for meaning rather than judging something over face value is a sign of an educated person.

You would expect more of those types on HN, but instead there's seemingly a crowd of predominantly hyperopinionated tinkerer-types.

[Profan]

One should be careful to not box people in too much, of course HN is full of tinkerer-types though (i mean, it's in the name), but I don't see that as the opposite of someone who is possible of searching for meaning, that's just absurd.

Judge people less, it doesn't do you any good, and it doesn't breed better discussion.

You're doing the exact same judging by going "I'm tired of having discussions on HN for this exact same reason..".

Just do your best to contribute and don't fuel the flames when things start going downhill, it's (imo) the best way breed an overall better environment.

[olalonde]

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)

[chipotle_coyote]

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

For a practical example of the metadata, albeit not one from MacOS: BeOS had a similar concept of file attributes as key/value pairs, and some MP3 players would store ID3 tags in files. In a directory window, you could list any custom attributes as columns. When I was a BeOS user, that made it trivially easy to use the file system itself as my answer to iTunes: windows would show artist, album, song title, track number, and playing times (or whatever I wanted), and because you could search on custom attributes and then save those searches as virtual folders, you could easily set up the equivalent of smart playlists.

[krylon]

That sounds kind of awesome!

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.

[mtone]

Howerver, in NTFS at least, attributes/metadata is a pretty flexible database-like storage, yet are not the same thing as alternate streams (a.k.a. resource forks) which are also supported.

[ksherlock]

"Originally conceived and implemented by programmer Bruce Horn, the resource fork was used for three purposes with Macintosh file system. First, it was used to store all graphical data on disk until it was needed, then retrieved, drawn on the screen, and thrown away. This software variant of virtual memory helped Apple to reduce the memory requirements of the Apple Lisa from 1 MB to 128 KB in the Macintosh. Second, because all the pictures and text were stored separately in a resource fork, it could be used to allow a non-programmer to translate an application for a foreign market, a process called internationalization and localization. And finally, it could be used to distribute nearly all of the components of an application in a single file, reducing clutter and simplifying application installation and removal."

https://en.wikipedia.org/wiki/Resource_fork

[Sanddancer]

It's essentially a way to gather more information concerning a file/application without needing to fill the overall filesystem with fairly irrelevant data. So it's a natural place for things like the third-party fonts a program needs, the data files that a program uses, the settings a program has, etc. For example, a game could have a save file that's simply named Blah.sav, but in the data streams, it could have Blah.sav:Save1, Blah.sav:Save2, etc

[Uberphallus]

Which is basically doable with folders.

[tjohns]

Sure, but if you're browsing the filesystem directly, it looks much cleaner.

Remember that MacOS users spend much more time working directly with the filesystem, because (recent developments with Launchpad aside) there's no analog to Windows' Start Menu. Literally everything is done by navigating directly through your hard drive in Finder. So keeping related files nicely bundled together and tidy is a bigger priority.

(You can also do neat things, like record whether a file was downloaded from the Internet, and from where -- and use that data to display a security warning when a foreign file is first opened. This would be very cumbersome to implement without extended attributes or resource forks.)

[Vendan]

so don't go into the app's directory and you don't see the extra files. Keep in mind, the start menu on windows is LITERALLY just a set of folders in your home directory, with a somewhat nice interface on top of them.

[lobo_tuerto]

Do you think that a flag for irrelevant content would help? Or just plain flagging?

[dang]

Just plain flagging is just fine for cases like this. This article has indeed been heavily flagged, which has made it rank lower on the front page. It has also gotten a lot of upvotes, which is why it's still on the front page.

[JupiterMoon]

As a counterpoint. I've only really been exposed to unix tradition files (bag of bytes). I learned something new and different from the discussion about this article. It's this kind of random knowledge that keeps me coming back to HN.