Ridiculous receipts

I still don't understand what any tiff file (even if
it's only one) is doing inside a receipt, not to
mention some of the other files in there, and why
many of these receipts have to be the size of the
complete works of shakespeare if they only serve as a
record of the installation.

A receipts package is more than just a simple record that something was installed. Think of it as a repository for metadata relating to the app & its installation, including resources that can be critical to the "it just works" behavior we expect from Apple. For instance, the package can tell you, the OS, or some utility if the referenced installer package requires a restart, is a required or optional installation, can overwrite a later version or not, requires updating other files (like installed languages), the default install location & number of files installed, & many other details about the installer itself.

Moreover, much of this metadata is in XML format, which means every item of info requires property & class tags as well as a value (the info itself). This is a very cool thing: any XML-aware app can find the info it needs without requiring that specific info about the metadata file format is coded into the app itself. So, while XML might more than double the size of the info file, it can save tons of file space by reducing the size of the code various apps might require to access it, as well as greatly improve stability & reliability of the app by verifying that the info is of the proper form (e.g., string, boolean, etc.) before trying to use it.

I do understand the need for different languages. But
the problem is that some of them contain lots of
non-language-specific items (like the identical tiffs
Quicktime651), which are then duplicated over all the
languages.

Different languages are only one part of localization. Think of localization as sets of resources specific to various geographic regions, which can cope with not just language differences but cultural & legal ones as well. Again, this is a very cool thing: it allows apps to be written independently of these considerations, which otherwise could lead to very bloated apps.

For instance, an image that is perfectly acceptable in one culture may be offensive or meaningless in another, or infringe on some local copyright or its equivalent. Instead of including a direct reference to the image file in the app, if the reference is to a lookup in the localization, the differences can be handled systematically by the OS, which is aware of the location(s) chosen by the user(s), instead of by the app, which probably isn't.

Also, lots of space is still being wasted in other
areas. Like a package with 700 individual little tiff
files (each one a block on the disk), while they
could easily be bundled in one big tiff file, etc,
etc...

Bundling is easy, but as the above should suggest, choosing the appropriate resources to use from the bundle can be challenging, particularly if you want the process to be transparent to the user(s), consistent across apps (including core OS ones that run behind the scenes), & efficient both in terms of total file space & code execution.

IOW, the knowledge to handle arbitrary data structures has to be stored somewhere if you want your Mac to have that functionality. The choice boils down to storing it on the hard drive & letting the machine use it directly or storing it in your head & feeding it to the machine as required.

I think it is an easy choice to make. 😉

Don't think of the size requirement in terms of storing data but in terms of the much more formidable challenge to encode knowledge about what the data means into forms the OS can understand & use.

It is analogous to storing a paper receipt's literal content vs. storing that plus how to identify & classify every item on it (like as a description, a price, or whatever), all in a way that it can be adapted to any language or culture for whatever purpose someone may devise.

In this frame of reference, a megabyte is a very modest amount of storage space.

Ok, true. Point taken.

I must admit, my receipts folder is 141MB and is too large for my liking. Periodically I go through it and purge manually. But the average system user will never do this just like the average PC user never deletes temporary files (and they can end up with GB of them!).

I had to know to do it, somehow a couple of years back I stumbled across the receipts folder and just had a look about. After I went from Panther to Tiger I figured it was ok to delete the Panther stuff, for example.

I agree and probably not.

There's too much wasted storage on today's system. Just like in real life, people see no need not to waste so why not just fill up MB/GB just because you can and there's plenty more. Bad, bad philosophy.

Do not alter the contents of or remove your 'Receipts' folder.

Free up space elsewhere or buy another bigger or extra internal Hard Drive or a large external one.

Mark

That seems to be everyone's solution, "Get a bigger Hard Drive". Hardly an excuse for filling the receipts folder with useless never referred to again stuff. While I appreciate much of the info there is necessary for the "It Just Works" to work, I am convinced the files/packages are bloated and do not need to be nearly the size they are. Just because the space is there, we do not HAVE to fill it.

Additionally, what about Joe Public who never reads these discussions and thinks, "ah, I can get rid of all those unwanted old receipts" and deletes them all?

Had I not figured out a few years back what they were for, I would have been inclined to delete them all to free up space thinking they would receipts and therefore optional to retain. They are, of course, not very optional. You need most of them retaIned.

What I don't understand is: what's all this
stuff doing in a receipt?

As I said, don't consider these file packages only as installer receipts but as the OS's repository for just about any resources relating to the installation that isn't part of the installed app itself. Resources are available assets that may be used for various purposes, not all of them defined beforehand. (A bank account is an example of such a resource.) I can't tell you exactly what Apple had in mind for some of the files in these packages or which ones are safe to delete, since that might depend in part on things yet to be developed or needed only for special purposes you may never encounter.

Like with anything else the OS normally maintains, you modify or delete them yourself at your own risk, since doing so may or may not break some process you don't understand or are aware of.

And then don't get me started about XML 😉
The information whether or not the computer
needs to be restarted, could be encoded in 1 bit.

Sure, but how many bytes of supporting code would it take to reliably extract that one bit of info from an arbitrary file structure for use with any app that required something from it? Would you prefer that every app that might possibly want access to any of the file's info individually maintain its own private routines & tables to understand, parse, & validate the file's content? What a nightmare that would be: every time such a file's organization changed, every app that used it would have to be revised to maintain its functionality & reliability. And the code bloat would be enormous, even if every app developer stayed on top of the changes.

XML is HTML on steroids. HTML defines a limited number of tags that encode how content can be displayed, but encode nothing about the information that content represents. As a result, that info can't reliably be extracted to be used for other than display purposes without human help. XML doesn't define specific info tags, it defines a systematic method of defining & creating them. As a result, any information can be made available in a form that machines or humans can use reliably for whatever purpose is desired.

Does this increase file size? You better believe it! Not only must you consider the size of the tagged file itself but of the defining reference & other documents that support it. But consider that this enables many platforms running many languages to parse, display, edit, exchange, and validate XML documents.

This is, as one Mr. Jobs might say, an insanely great thing. Instead of being limited to exchanging bits that mean nothing outside of a very specific & limited context that must be defined individually for every use, platform, & programming language, our computers can now exchange information in much the same way humans can, knowing (for example) what the bit representing 'restart required' means in any context that would be useful.

I have no idea what Apple ever intends to do with them. I can see no useful function for them at all.

Then, by all means, delete them. It's your machine and you can do anything you wish with it. If that action hoses it up, then you'll have to live with the consequences. If you have a better way, consider developing your own operating system and joining the millionaires club.