4 ms·

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.

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.

andrewmcwatters 11y ago
I'm tired of having discussions with people on HN for this very reason. It's such a joke.
- dang 11y ago
  Please stop posting comments that lower the quality of the site even further. Instead, post nothing or find a way to improve the discussion. Quite a few users have done so in this very thread, so you needn't look far for inspiration.
Profan 11y ago
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!
- andrewmcwatters 11y ago
  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 11y ago
    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.
- saidajigumi 11y ago
  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 11y ago
    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.
- rconti 11y ago
  I don't read the blogpost the same way. I read it as confident condescension.
lobo_tuerto 11y ago
Do you think that a flag for irrelevant content would help? Or just plain flagging?
- dang 11y ago
  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.
olalonde 11y ago
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)
- Sanddancer 11y ago
  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 11y ago
    Which is basically doable with folders.
    - tjohns 11y ago
      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 11y ago
        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.
mborsuk 11y ago
yes. how often do you click some top voted link and it starts off sounding like it's going to be some in-depth and provocative analysis and it turns out the author only learned how to copy that style of that writing so the post abruptly ends when he's reached the limit of his ability, which just like this post, is pretty quickly.
JupiterMoon 11y ago
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.

andrewmcwatters 11y ago

I'm tired of having discussions with people on HN for this very reason. It's such a joke.

dang 11y ago
Please stop posting comments that lower the quality of the site even further. Instead, post nothing or find a way to improve the discussion. Quite a few users have done so in this very thread, so you needn't look far for inspiration.

Profan 11y ago

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!

andrewmcwatters 11y ago
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 11y ago
  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.
saidajigumi 11y ago
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 11y ago
  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.
rconti 11y ago
I don't read the blogpost the same way. I read it as confident condescension.

lobo_tuerto 11y ago

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

dang 11y ago
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.

olalonde 11y ago

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)

Sanddancer 11y ago
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 11y ago
  Which is basically doable with folders.
  - tjohns 11y ago
    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 11y ago
      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.

mborsuk 11y ago

yes. how often do you click some top voted link and it starts off sounding like it's going to be some in-depth and provocative analysis and it turns out the author only learned how to copy that style of that writing so the post abruptly ends when he's reached the limit of his ability, which just like this post, is pretty quickly.

JupiterMoon 11y ago

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.