memling
Joined 8 years ago
Joined 8 years ago
Good question. I was thinking of the transitions in the '80s, although my experience with standards written during that time is very limited.
But yes, one of the reasons people use ASN.1 is because of its hard and fast commitments to backwards compatibility.
I don't recall saying that—just that I have had clients for whom the support was sufficiently important (because of their own reliability concerns) that they went commercial instead of open source. (They required, among other things, 24x7 support and dedicated resources to fix bugs when found; they also sought guarantees on turn-around time.)
If your business depends on five nines plus of reliability in your 5g communications stack, you might be willing to fork over the price for it. Or if you need a bug fix made in a timely fashion to the compiker or runtime, likewise. As I've noted above, a client of mine moved to a commercial suite of tools for this reason.
Protobuf and flatbuffers have different use cases in my experience, although that's somewhat limited. Protobuf at least also introduced breaking changes between versions 2 and 3. ASN.1 isn't perfect in this regard, but these days incompatibikities have to go through ISO or ITU, etc.
Your experience may be different of course. I'm just pointing out that there are reasons people will opt for a commercial product.
Oh sure--there are plenty of alternatives to ASN.1. My guess is that most people who have the choice don't use ASN.1 precisely because open-source alternatives exist and can feasibly work for most use cases.
But if you happen to have one of the use cases that require ASN.1, open sourced tooling can be problematic precisely because of the need for a robust SLA.
You're buying more than a compiler and runtime, though: you're also getting an SLA and a stricter guarantee about interoperability and bugs and so forth. I have no idea how good their support is (maybe it's atrocious?), but these are important. I had a client who relied on the open-sourced asn1c once who complained about some of the bugs they found in it; they got pushed into buying commercial when the cost-benefit outweighed the software licensing issues.
This is mind-blowing, but it would be surprising to find this would happen without additional consequences. A friend of mine was ticketed for 20 MPH over the speed limit (not in California) and had his license suspended. Most states in the US adopt a points-based system that triggers suspension when you acquire sufficient numbers. California is no different.
So I generally agree with your post, but is this what constitutes early riser these days? I get having kids and missing the key 7-9am time slot, but is an 11am start time a Usual Thing?
This is the thesis to the introduction to Jonathan Haidt's The Righteous Mind. Boiling it down, he argues that self-justification is the most fundamental human reaction. We reason after, not before, and our reasoning flows to align with our own justification.
(Luther would be proud.)
Can you expand on this a bit? I have an intuition about what you're saying, but I confess that the definitions can be a little slippery.
For my part, though, I'm typically authoring print documents in LyX, since I don't have to exchange documents routinely. If I do have to share Word-compatible documents, I'll sometimes use LO Writer or else convert from a text format to .docx using pandoc.
Proto2 and Proto3 differ in how they handle default and required elements. Regarding these differences, I found a few references online:
I don't use protobuf regularly, and they claim that the wire formats are bidirectionally compatible. When I last evaluated them with another developer years ago, I don't recall this being the case. (It was not merely a difference between their syntaxes.) I'm not sure the semantics are preserved between the two versions, either (e.g., did I provide a default value? was this element optional and missing? etc.).They have lately (this is news to me) moved to protobuf editions: https://protobuf.dev/editions/overview/. This provides some flexibility in the code generation and may require some maintenance on the part of the user to ensure that codec behavior remains consistent. Google, for their part, are trying to minimize these disruptions:
> When the subsequent editions are released, default behaviors for features may change. You can have Prototiller do a no-op transformation of your .proto file or you can choose to accept some or all of the new behaviors. Editions are planned to be released roughly once a year.