171–180 of 211 posts
Earlier quoted context omitted.
You wouldn't put the entire content of a file in an extended attribute, would you?
In Classic Mac OS, most executables consisted entirely of resource forks. Even the code was stored in resources of type CODE.
Earlier quoted context omitted.
In Classic Mac OS, most executables consisted entirely of resource forks. Even the code was stored in resources of type CODE.
PowerPC executables stored code in the data fork.
Earlier quoted context omitted.
I prefer the less verbose version: "Don't just do something. Stand there." --Marvin Minsky
http://quoteinvestigator.com/2014/03/22/stand-there/
Here's a link to Minsky's Law (actually two):
https://edge.org/response-detail/11644
If I recall correctly, it's also mentioned in The Society of Mind.
Earlier quoted context omitted.
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…
> an amazingly well-designed OS for its time It had a few interesting ideas. But no desktop OS based on cooperative multitasking can be called 'well-designed', almost anything could hard-lock the entire system at any time.
How do you even build applications?
Earlier quoted context omitted.
Actually, I believe OS X does this for small files in order to not burn a whole filesystem block on a sub 1k file. "In Mac OS X Snow Leopard 10.6, HFS+ compression was added. In open source and some other areas this is referred to as AppleFSCompression. Compressed data may be stored in either an extended attribute or the resource fork.[13] When using non-Apple APIs, AppleFSCompression is not always completely transpa…
FS compression is transparent to any regular file-reading API; it only shows up in lower-level APIs, like if you want to copy the file and keep the compression.
Earlier quoted context omitted.
PowerPC executables stored code in the data fork.
Ah, good to know. My last Mac was m68k (Performa 630CD, one of the very last m68k models), so my memories include seeing plenty of CODE resources when playing around with ResEdit.
That's not actually true. Most if not all Unix utilities have been updated to deal with resource forks, and they have been integrated into the Unix directory hierarchy by treating the actual file as a single level directory.
The fact that the resource fork is invisible by default is the most reasonable way I can think of. Other options such as concatenating all the forks together or treating the file itself as a single level directory by default would actually break everything.
The solution that they found is to have this interpretation (the file is really a single-level directory) accessible, but make one fork (the data fork) the default "bag of bytes" for most of the Unix tools.
For example:
file /tmp/Euclid/..namedfork/rsrc
/tmp/Euclid/..namedfork/rsrc: MS Windows icon resource
That was a copy of a resource-fork based font I created by typing:
cp Euclid /tmp/
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.
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 resou…
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 vir…