Live data from Hacker News

A deep dive into Apple's .car file format

dbg.re

71–73 of 73 posts

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

#71

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

> Don't use binary formats when it isn't absolutely needed. JSON in particular isn't very good [0] but I'd also argue that text formats in general aren't great. Isn't it a lot better that an int32_t always takes exactly 4 bytes instead of anywhere between one and eleven bytes (-2147483648)? [0] https://news.ycombinator.com/item?id=40555431

I would agree that binary formats can be much better. Sometimes you can use fixed fields, but there are also structured formats such as DER (which is generally better than JSON in my opinion). JSON has many problems, including that it does not have a non-Unicode type (so you must use base64 encoding or hex encoding instead and that isn't very good), and other problems. Parsing it will also mean that you must handle escaping.

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

#72

Earlier quoted context omitted.

rly. Ran on two different Macs. Works up to Tahoe 26.2. Maybe depends on developer tools installed?

Is the feedback that instead of a short web search, I could "simply" have checked the man page on a different computer, after confirming dev tools are installed?

What a place HN is that this is the default assumption of intent, lol

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

#73

Earlier quoted context omitted.

Is the feedback that instead of a short web search, I could "simply" have checked the man page on a different computer, after confirming dev tools are installed?

What a place HN is that this is the default assumption of intent, lol

But like, you knew you were being a bit of a smart aleck in your first reply. I was just matching snark-for-snark ;)
Post reply on HN