ornxka
Joined 6 years ago
Joined 6 years ago
- Charles Colson, advisor to Richard Nixon during the Watergate scandal
I think the world would be a much better place if we stopped treating programmatic access to interfaces differently than human access to it. Anybody can learn to code.
Or, to elaborate, these things have a cost whether people are aware of it (and care about it) or not. Maybe it's not so high now, but eventually it's likely to manifest itself, especially when the codebase needs to run in a new environment or be modified to follow a new paradigm. Those situations are where things tend to either "make the jump" and continue to be used or end up in the (already vast) graveyard of abandoned software because the cost of maintaining it became higher than the return it yielded.
If its scarcity isn't real, then why can't you conjure up an arbitrary number of bitcoins at will?
Is it? What if the alternative is that people feel the wrong way about things?
>Compiler writers and tool authors are perfectly comfortable working with binary file formats. There's nothing more inherently future-compatible about JSON than a forward-compatible binary format like flatbuffers. Having to escape and then unescape naughty bytes is a huge downside for text-based formats that are hardly ever read by humans.
Well, the problem isn't binary or non-binary, the problem is that these formats like ELF are, apparently, really annoying to deal with, have weird limitations, and are difficult to extend. The reason I thought of JSON in particular is because it doesn't really need to be extended to encode anything (unless you include escaping or base64 encoding binary data you want to put inside of a JSON document as "extending" it). You can encode all of the fields in ELF (or any other format) inside of JSON, while it doesn't make sense to consider the converse because ELF has fixed fields with fixed meanings.
That's the problem with these bespoke binary formats like ELF - they're not designed to encode arbitrary schemas of data, they're designed for very specific tasks and then when they get used outside of their intended environment, we get problems like have been described in this thread. Nobody has ever had these problems with a JSON document - maybe with something that consumed one, but the file format itself simply does not have the same kind of limitations like ELF does. It has different limitations, but they're not of a fundamental and semantic nature like they are in a more rigid format.
You're right that it would be a problem to have to escape/unescape every section every time you wanted to run something because that's very slow, but I think that's basically the only problem that these bespoke binary formats solve. If that's the case, I wonder why something like Matroska wouldn't work for binaries? My understanding is that it's basically binary XML and allows for basically a completely arbitrary dictionary structure. It doesn't have nice tooling like JSON or XML do, but there's no weird restrictions on things like field length that I'm aware of. I guess it doesn't exactly have any "momentum", though, but maybe the NixOS people will get sick enough of ELF to consider such a drastic solution :P
qmail is written in C, and it has never had a serious security hole that I am aware of. Not all C code is unsafe.
[1] In general, I mean - I actually don't use AWS.