4 ms·

I don’t think people these days realize how interesting pre-X pre-UNIXification MacOS Classic was. Single files often were made of multiple data streams “resou

by donatj 4y ago

I don’t think people these days realize how interesting pre-X pre-UNIXification MacOS Classic was. Single files often were made of multiple data streams “resource forks”, and this was actually utilized heavily (NTFS has a similar concept but it’s almost never used). Files had “creator codes” as metadata rather than file extensions. They were directly and firmly associated with the application that created them rather than a description of their content. Files in and of themselves were a very different concept in MacOS Classic. In my eyes a big part of what killed this was the Internet. To the Internet, a file is clearly only a single stream of data. Files are typed by content via mime and file extension, not what created it. Anything with resource forks need to be bundled in a .sit file. This is clearly inconvenient, and made MacOS files second-class citizens. Mind you, resource fork still exist in macOS today, they’re just used for custom icons, tags and file comments. Metadata. Nothing to the extent that MacOS Classic used them for, and all things users don’t mind losing on uploading to the web. - https://www.macintoshrepository.org/articles/152-what-is-a-sit-stuffit-file-and-how-to-use-it- https://www.macintoshrepository.org/articles/152-what-is-a-s...

jstimpfle 4y ago
Sounds like a layering issue to me. We have enough problems with semantic differences between filesystems on different platforms - permission models, allowed characters in names etc. What is a strong reason why the multiple streams shouldn't just be implemented on top of a single-stream filesystem file abstraction? I know a number of formats that do such a thing, like ELF, PDF, Sqlite3, various media containers, various archive formats.. Probably some people here can come up with dozens without looking anything up. If you do these resource streams, how do you copy those to various other mediums, like physical drives, tapes, pipes, sockets... All consist only of a single stream at a low level, because why make it harder than that? Now that means that instead of "cat" your standard way to read such a multi stream file would be a command that serializes it to the "sit" format as you mentioned, making that format almost the canonical representation. So what was he point of implementing these resoure forks in the filesystem again? Critizicing Unix often comes back to the "reinventing poorly" phrase, the simplicity of not having some features at every layer is a virtue.
- lproven 4y ago
  I strongly disagree. The problem with the Unix lowest-common-denominator model is that it pushes complexity out of the stack and into view, because of stuff other designs _thought_ about and worked to integrate. It is very important never to forget the technological context of UNIX: a text-only OS for a tiny, already obsolete and desperately resource-constrained, standalone minicomputer. It was written for a machine that was already obsolete, and it shows. No graphics. No networking. No sound. Dumb text terminals, which is why the obsession with text files being piped to other text files and filtered through things that only handle text files. While at the same time as UNIX evolved, other bigger OSes for bigger minicomputers were being designed and built to directly integrate things like networking, clustering, notations for accessing other machines over the network, accessing filesystems mounted remotely over the network, file versioning and so on. I described how VMS pathnames worked in this comment recently: https://news.ycombinator.com/item?id=32083900 https://news.ycombinator.com/item?id=32083900 People brought up on Unix look at that and see needless complexity, but it isn't. VMS' complex pathnames are the visible sign of an OS which natively understands that it's one node on a network, that currently-mounted disks can be mounted on more than one network nodes even if those nodes are running different OS versions on different CPU architectures. It's an OS that understands that a node name is a flexible concept that can apply to one machine, or to a cluster of them, and every command from (the equivalent of) `ping` to (the equivalent of) `ssh` can be addressed to a cluster and the nearest available machine will respond and the other end need never know it's not talking to one particular box. 50 years later and Unix still can't do stuff like that. It needs tons of extra work with load-balancers and multi-homed network adaptors and SANs to simulate what VMS did out of the box in the 1970s in 1 megabyte of RAM. The Unix was only looks simple because the implementors didn't do the hard stuff. They ripped it out in order to fit the OS into 32 kB of RAM or something. The whole point of Unix was to be minimal, small, and simple. Only it isn't any more, because now we need clustering and network filesystems and virtual machines and all this baroque stuff piled on top. The result is that an OS which was hand-coded in assembler and was tiny and fast and efficient on non-networked text-only minicomputers now contains tens of millions of lines of unsafe code in unsafe languages and no human actually comprehends how the whole thing works. Which is why we've build a multi-billion-dollar industry constantly trying to patch all the holes and stop the magic haunted sand leaking out and the whole sandcastle collapsing. It's not a wonderful inspiring achievement. It's a vast, epic, global-scale waste of human intelligence and effort. Because we build a planetary network out of the software equivalent of wet sand. When I look at 2022 Linux, I see an adobe and mud-brick construction: https://en.wikipedia.org/wiki/Great_Mosque_of_Djenn%C3%A9#/media/File:Djenne_great_mud_mosque.jpg https://en.wikipedia.org/wiki/Great_Mosque_of_Djenn%C3%A9#/m... When we used to have skyscrapers. You know how big the first skyscraper was? 10 floors. That's all. This is it: https://en.wikipedia.org/wiki/Home_Insurance_Building#/media/File:Home_Insurance_Building.JPG https://en.wikipedia.org/wiki/Home_Insurance_Building#/media... The point is that it was 1885 and the design was able to support buildings 10× as big without fundamental change. The Chicago Home Insurance building wasn't very impressive, but its design was. Its design scaled. When I look at classic OSes of the past, like in this post, I see miracles of design which did big complex hard tasks, built by tiny teams of a few people, and which still works today. When I look at massive FOSS OSes, mostly, I see ant-hills. It's impressive but it's so much work to build anything big with sand that the impressive part is that it works at all... and that to build something so big, you need millions of workers, and constant maintenance. If we stopped using sand, and abandoned our current plans, and started over afresh, we could build software skyscrapers instead of ant hills. But everyone is too focussed on keeping our sand software working on our sand hill OSes that they're too busy to learn something else and start over.
WillAdams 4y ago
Give me a bundle of files w/ an extension instead. .rtfd is quite nice and it's easy to re-use all the elements of a document.
asveikau 4y ago
The coolest thing about resource forks is how it encouraged separation of data and code. You could often alter a program's behavior and UI in ResEdit without modifying any code.

by donatj 4y ago

jstimpfle 4y ago

Sounds like a layering issue to me. We have enough problems with semantic differences between filesystems on different platforms - permission models, allowed characters in names etc. What is a strong reason why the multiple streams shouldn't just be implemented on top of a single-stream filesystem file abstraction? I know a number of formats that do such a thing, like ELF, PDF, Sqlite3, various media containers, various archive formats.. Probably some people here can come up with dozens without looking anything up. If you do these resource streams, how do you copy those to various other mediums, like physical drives, tapes, pipes, sockets... All consist only of a single stream at a low level, because why make it harder than that? Now that means that instead of "cat" your standard way to read such a multi stream file would be a command that serializes it to the "sit" format as you mentioned, making that format almost the canonical representation. So what was he point of implementing these resoure forks in the filesystem again? Critizicing Unix often comes back to the "reinventing poorly" phrase, the simplicity of not having some features at every layer is a virtue.

lproven 4y ago
I strongly disagree. The problem with the Unix lowest-common-denominator model is that it pushes complexity out of the stack and into view, because of stuff other designs _thought_ about and worked to integrate. It is very important never to forget the technological context of UNIX: a text-only OS for a tiny, already obsolete and desperately resource-constrained, standalone minicomputer. It was written for a machine that was already obsolete, and it shows. No graphics. No networking. No sound. Dumb text terminals, which is why the obsession with text files being piped to other text files and filtered through things that only handle text files. While at the same time as UNIX evolved, other bigger OSes for bigger minicomputers were being designed and built to directly integrate things like networking, clustering, notations for accessing other machines over the network, accessing filesystems mounted remotely over the network, file versioning and so on. I described how VMS pathnames worked in this comment recently: https://news.ycombinator.com/item?id=32083900 https://news.ycombinator.com/item?id=32083900 People brought up on Unix look at that and see needless complexity, but it isn't. VMS' complex pathnames are the visible sign of an OS which natively understands that it's one node on a network, that currently-mounted disks can be mounted on more than one network nodes even if those nodes are running different OS versions on different CPU architectures. It's an OS that understands that a node name is a flexible concept that can apply to one machine, or to a cluster of them, and every command from (the equivalent of) `ping` to (the equivalent of) `ssh` can be addressed to a cluster and the nearest available machine will respond and the other end need never know it's not talking to one particular box. 50 years later and Unix still can't do stuff like that. It needs tons of extra work with load-balancers and multi-homed network adaptors and SANs to simulate what VMS did out of the box in the 1970s in 1 megabyte of RAM. The Unix was only looks simple because the implementors didn't do the hard stuff. They ripped it out in order to fit the OS into 32 kB of RAM or something. The whole point of Unix was to be minimal, small, and simple. Only it isn't any more, because now we need clustering and network filesystems and virtual machines and all this baroque stuff piled on top. The result is that an OS which was hand-coded in assembler and was tiny and fast and efficient on non-networked text-only minicomputers now contains tens of millions of lines of unsafe code in unsafe languages and no human actually comprehends how the whole thing works. Which is why we've build a multi-billion-dollar industry constantly trying to patch all the holes and stop the magic haunted sand leaking out and the whole sandcastle collapsing. It's not a wonderful inspiring achievement. It's a vast, epic, global-scale waste of human intelligence and effort. Because we build a planetary network out of the software equivalent of wet sand. When I look at 2022 Linux, I see an adobe and mud-brick construction: https://en.wikipedia.org/wiki/Great_Mosque_of_Djenn%C3%A9#/media/File:Djenne_great_mud_mosque.jpg https://en.wikipedia.org/wiki/Great_Mosque_of_Djenn%C3%A9#/m... When we used to have skyscrapers. You know how big the first skyscraper was? 10 floors. That's all. This is it: https://en.wikipedia.org/wiki/Home_Insurance_Building#/media/File:Home_Insurance_Building.JPG https://en.wikipedia.org/wiki/Home_Insurance_Building#/media... The point is that it was 1885 and the design was able to support buildings 10× as big without fundamental change. The Chicago Home Insurance building wasn't very impressive, but its design was. Its design scaled. When I look at classic OSes of the past, like in this post, I see miracles of design which did big complex hard tasks, built by tiny teams of a few people, and which still works today. When I look at massive FOSS OSes, mostly, I see ant-hills. It's impressive but it's so much work to build anything big with sand that the impressive part is that it works at all... and that to build something so big, you need millions of workers, and constant maintenance. If we stopped using sand, and abandoned our current plans, and started over afresh, we could build software skyscrapers instead of ant hills. But everyone is too focussed on keeping our sand software working on our sand hill OSes that they're too busy to learn something else and start over.

WillAdams 4y ago

Give me a bundle of files w/ an extension instead. .rtfd is quite nice and it's easy to re-use all the elements of a document.

asveikau 4y ago

The coolest thing about resource forks is how it encouraged separation of data and code. You could often alter a program's behavior and UI in ResEdit without modifying any code.