111–120 of 211 posts
http://www.folklore.org/StoryView.py?story=The_Grand_Unified...
If you want to know more about the invention and early history of the Macintosh in general, there's tons more at http://www.folklore.org (or in the book based on it, Revolution in The Valley, by Andy Hertzfeld).
Earlier quoted context omitted.
Which? Apple won't adopt anything GPL, so BTRFS, XFS, JFS, etc--basically every Linux project is right out. It was almost ZFS, years ago, but Apple backed out when Oracle bought Sun. What out there is modern, good, and under a compatible license? HAMMER?
They could probably buy up the rights to BeFS for really cheap now. It was a beautiful file system, in my opinion.
Earlier quoted context omitted.
> That said, I agree, it's a horrible design - but it's existed for 20+ years already. Actually there's absolutely nothing horrible about resource forks/extended attributes in theory. We use way worse ideas like "sidecar" files and metadata stored centrally for the same use cases, which are worse ways to handle the issue. The real problem is the lack of agreement/interoperability in handling them across FSs (and perh…
Who cares if it's a fine idea in theory, when in reality it's completely unpractical. What you call 'worse' is a model that works. Files showing the wrong size are a very small part of the problem. If people actively start storing critical data in resource forks (as it was done in the case of the font), a lot of other things will break. Just think of the humble HTML upload form or Git. Almost everywhere a file is con…
Anyone who's ever worked with Macs - including software writers, tool writers, developers, know about resource forks - and it's fine because major tools have been rewritten to be resource fork aware.
Nothing's really gone wrong in the sense of reality and while there may be hiccups, you don't really see users actually complain about resource forks.
It's the hypothetical case where "people actively start storing critical data ..." etc. In this case, those people haven't done their homework about the mac platform. Like the Original Post of this HN thread - this person clearly hasn't read the docs re: resource forks and is hacking around, assuming that the mac should be like any of the platforms they've used before, and complaining when it is different.
There are also extensive - majorly detailed documentation from Apple themselves re how resource forks are used and in which circumstances:
https://developer.apple.com/search/?q=%22resource%20fork%22
That gives a ton of hits. Just read the docs. Really.
Again, I pull out the old Windows example moving from FAT to FAT32
8.3 filenames -> Long filenames contains a backwards compatible way to truncate long filenames back down to 8.3. So what if someone stores critical information in the long filename that is suddenly lost when round-tripping through an OS that doesn't understand long file names? SHOCK!! HORROR! Reality is no one does that. End of story.
https://en.wikipedia.org/wiki/Long_filename
Platforms are different! just learn what's different so that you don't get caught unaware.
Alternate parts to the main file are present on several platforms, and have the same problems. They are called resource forks on Mac. On Windows/NTFS they are called alternate data streams - https://en.wikipedia.org/wiki/Fork_(file_system) - to use specify a colon and name after the filename (eg example.txt:myads). On Unix, Linux, OS/2 etc you can find extended attributes - https://en.wikipedia.org/wiki/Extended_file…
http://arstechnica.com/apple/2005/04/macosx-10-4/7/#extended...
Today, resource forks are actually exposed through the extended attributes interface:
http://arstechnica.com/apple/2013/10/os-x-10-9/9/#tags-imple...
You can see the source code for all this in Apple's Darwin open source repository. Example: http://opensource.apple.com/source/xnu/xnu-2782.40.9/bsd/hfs...
Please read this, written by the creator of resource forks, to learn why they exist:
http://www.folklore.org/StoryView.py?story=The_Grand_Unified...
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
There's a difference between having a feature you want everyone to use, vs. having a feature that only exists for very specific legacy reasons in very specific systems-level backwards-compatibility scenarios, that you don't want anyone to use under any circumstances. Exposing the feature more than it already is exposed would be far more confusing and hurtful to new computer users, most of whom don't understand working with filesystems in general much less specific low-level filesystem features like resource forks.
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 mai…
Earlier quoted context omitted.
The problem is that *nix tools only support technology that existed in 1972. Anything newer than that is screwed. Mac Classic's death knell was the increasing popularity of the Internet. Run by servers that couldn't possibly store Mac Classic files correctly, because guess what? Resource forks/alternative data streams/whatever didn't exist back in 1972. And yes I am still bitter about this.
That's an important point. I think however elegant for its time the 70s/early 80s UNIX design, it holds us back in many ways. It's amazing that we still widely use a language without a string type and memory safety like C for example, instead of something like Rust, Swift and co -- with occasional excursions to unsafety maybe for speed/interoperability with older libs, but not as the default for the whole goddamn cod…
That is misrepresenting (perhaps to the point of straw man) the systemd complaints.
Alternate parts to the main file are present on several platforms, and have the same problems. They are called resource forks on Mac. On Windows/NTFS they are called alternate data streams - https://en.wikipedia.org/wiki/Fork_(file_system) - to use specify a colon and name after the filename (eg example.txt:myads). On Unix, Linux, OS/2 etc you can find extended attributes - https://en.wikipedia.org/wiki/Extended_file…
You wouldn't put the entire content of a file in an extended attribute, would you?
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 mai…
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 migh…
Resource forks were pretty cool, actually: they were a simple database attached to every file, which could be used to store metadata or other information. It was pretty common for applications to store fonts, icons &c. all in their resource forks. Back when I was a kid I used to use ResEdit to change application & file icons, fiddle with GUI controls, change menu structures and so on. Happy days!
More info on how it worked: https://en.wikipedia.org/wiki/Plug-in_(Escape_Velocity) (why this is a relevant article in Wikipedia, I have no idea.)
Note to anyone reading this, though: If you're designing a system from scratch, don't even think about using resource forks to store data. Just say no.