Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A deep dive into Apple's .car file format

dbg.re

Post reply on HN
Print view View original

31–40 of 73 posts

Re: A deep dive into Apple's .car file format

#31

Post by taneq »

lpcvoid wrote: post #9
silvestrov wrote: post #2

Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.

Strong disagree. I like binary formats because I can just fopen(), fseek() and fread() stuff. I don't need json parser dependency, and don't need to deal with compression. Binary formats are simple, fast and I need a way smaller buffer to read/write them normally. I don't like wasting resources.

Binary formats (that you can just fopen(), fseek(), fread() etc.) are generally super platform dependent. You can read in an array of bytes and then manually deserialise it (and I’ve done this, for sure!) but that’s basically one step away from parsing anyway.

Re: A deep dive into Apple's .car file format

#32

Post by nxobject »

wzdd wrote: post #24

The fact that different parts of the file use different endiannesses really added that special Apple tech flavour.

The BOM file format is very, very old - I think for the first decade of its life it actually lived on big-endian platforms (m68k/SPARC/PA-RISC NeXTSTEP, and then over to Apple and big-endian PowerPC.)

EDIT - someone needs to crack open x86 OPENSTEP and do some grepping for 'RATC'...

Re: A deep dive into Apple's .car file format

#33

Post by sigseg1v »

lpcvoid wrote: post #11
empiricus wrote: post #10

Idea: pass the decompiled code through a "please rename variables according to their purpose" step using a coding agent. Not ideal, but arguably better than v03, v20. And almost zero effort at this time and age.

And have it hallucinate stuff? Nah, this stuff is hard enough without LLMs guessing.

If you ask an LLM to do a statically verifiable task without writing a simple verifier for it, and it hallucinates, that mistake is on you because it's a very quick step to guarantee something like this succeeds.

Re: A deep dive into Apple's .car file format

#34

Post by drob518 »

peterspath wrote: post #22
silvestrov wrote: post #2

Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.

I choose binary formats over JSON almost every time I can. JSON sucks big time.

JSON is… adequate. I like binary formats, too, when doing low-level programming, but you often want something readable, and JSON is a lot better and easier to parse than many other things, say XML.

Re: A deep dive into Apple's .car file format

#35

Post by Cthulhu_ »

silvestrov wrote: post #2

Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.

JSON is for humans to read and maintain, not machines to read/write - and machines read/write millions of times more than humans do.

Using JSON / HTTP for backend communication (i.e. microservices) is madness when you consider how much overhead there is and how little value having it be human-readable delivers.

Re: A deep dive into Apple's .car file format

#36

Post by Cthulhu_ »

lpcvoid wrote: post #11
empiricus wrote: post #10

Idea: pass the decompiled code through a "please rename variables according to their purpose" step using a coding agent. Not ideal, but arguably better than v03, v20. And almost zero effort at this time and age.

And have it hallucinate stuff? Nah, this stuff is hard enough without LLMs guessing.

I'd argue that as long as it produced working code it's better than nothing, in this case.

Re: A deep dive into Apple's .car file format

#37

Post by pjmlp »

embedding-shape wrote: post #8
mort96 wrote: post #4

Earlier quoted context omitted.

Uh. You want to store assets in JSON? Why? You generally want asset packs to be seekable so that you can extract just one asset, and why would you want to add the overhead of parsing potentially gigabytes of JSON and then, per asset, decoding potentially tens of megabytes of base64?

> You want to store assets in JSON? Why? Why not have both options? .gltf and .glb being possible for assets been more than helpful to me more than once, having the option gives you the best of both worlds :)

Only because they were originally designed for Web 3D.

Re: A deep dive into Apple's .car file format

#38

Post by MrBuddyCasino »

mike_hearn wrote: post #19
silvestrov wrote: post #2

Looks very much like a format that should just have been gzipped JSON. Don't use binary formats when it isn't absolutely needed.

It's not new. BOMStore is a format inherited from NeXTStep. JSON didn't exist back then. Also, it's a format designed to hold binary data. JSON can't do that without hacks like base64 encoding. Binary file stores like this are very common in highly optimized software, which operating systems tend to be, especially if you go looking at the older parts. Windows has a similar format embedded in EXE/DLL files. Same conce…

You don't have to put the files in the json, you can just put them inside the gzip file. But yeah obviously these are different eras.

Re: A deep dive into Apple's .car file format

#39

Post by streetfighter64 »

sigseg1v wrote: post #33
lpcvoid wrote: post #11

Earlier quoted context omitted.

And have it hallucinate stuff? Nah, this stuff is hard enough without LLMs guessing.

If you ask an LLM to do a statically verifiable task without writing a simple verifier for it, and it hallucinates, that mistake is on you because it's a very quick step to guarantee something like this succeeds.

I mean, step 0 is verifying that the code with changed names actually compiles. But step 1, which is way more difficult, is ensuring that replacing v01 with out_file_idx or whatever, actually gives a more accurate description of the purpose of v01. Otherwise, what's the point of generating names if they have a 10% chance of misleading more than clarifying.

Re: A deep dive into Apple's .car file format

#40

Post by streetfighter64 »

empiricus wrote: post #15
lpcvoid wrote: post #11

Earlier quoted context omitted.

And have it hallucinate stuff? Nah, this stuff is hard enough without LLMs guessing.

Well, I mean just choosing better names, don't touch the actual code. and you can also add a basic human filtering step if you want. You cannot possible say that "v12" is better than "header.size". I would argue that even hallucinated names are good: you should be able to think "but this position variable is not quite correctly updated, maybe this is not the position", which seems better than "this v12 variable is up…

In case the variable describes the number of input files, then v12 is better than header.size. How can you be sure that adding some LLM noise will provide actually accurate names?
Post reply on HN