> In the ASN.1 space everyone hopes that someone can dethrone OSS Nokalva's proprietary solutions
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.
> Meh. After all, if you're not using ASN.1 you're using something like ProtocolBuffers or FlatBuffers or whatever and all open source tooling.
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.
> 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.
Why would you need a support SLA for ASN.1 and not for PB/FB? That makes no sense. And there's plenty of open source ASN.1 tooling now -- just look around this thread!
The difference is the quality of the OSS implementation: most OSS ASN.1 tool choke on the enormous 3GPP specs and others used in the telco industry, thus cannot generate 100% valid code.
For some use-cases, you can get by with manually adjust the generated code. That works until the hardware vendors release a new device that use a more modern 3GPP specs and your code start breaking again.
When using a commercial ASN.1 tooling, they often update their compilers to support the latest 3GPP specs even before the hardware vendors, and thus supporting a new device is way simpler.
If I got paid to write an 3GPP implementation one of the things I might do is make one open source ASN.1 stack really good. I've worked on open source projects as part of proprietary work.
> Why would you need a support SLA for ASN.1 and not for PB/FB? That makes no sense. And there's plenty of open source ASN.1 tooling now -- just look around this thread!
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.
> Protobuf and flatbuffers have different use cases in my experience, although that's somewhat limited.
This is true for the ASN.1 encoding rules as well.
> Protobuf at least also introduced breaking changes between versions 2 and 3. ASN.1 isn't perfect in this regard,
When has ASN.1 ever broken backwards compatibility? I've never heard of an ASN.1 backwards incompatibility. Maybe, if you stretch an interpretation of ASN.1 in 1984 to allow new fields to be added to `SEQUENCE { }` then the later addition of extensibility markers could count as a very weak backwards-incompatible change -- weak in that existing specs that use ASN.1 had to add those markers to `SEQUENCE { }`s that were actually intended to be extensible, but no running code was actually broken. I would be shocked if the ITU-T broke backwards compat for running code.
> When has ASN.1 ever broken backwards compatibility? I've never heard of an ASN.1 backwards incompatibility. Maybe, if you stretch an interpretation of ASN.1 in 1984 to allow new fields to be added to `SEQUENCE { }` then the later addition of extensibility markers could count as a very weak backwards-incompatible change -- weak in that existing specs that use ASN.1 had to add those markers to `SEQUENCE { }`s that were actually intended to be extensible, but no running code was actually broken. I would be shocked if the ITU-T broke backwards compat for running code.
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.
> But yes, one of the reasons people use ASN.1 is because of its hard and fast commitments to backwards compatibility.
To be fair I think that's generally expected of things like it. XDR? Stable. DCE/RPC? Obsolete, yes, but stable. MSRPC? A derivative of DCE/RPC, and yes, stable. XML? Stable. JSON? Stable. And so on. All of them stable. If PB broke backwards-compat once then to me that's a very serious problem -- details?
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.
> Does one pay for an SLA for every piece of hardware, firmware, and software? The codecs are the least likely cause of downtime.
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.)
I second this: don't go down the wrong entrance, but definitely do visit. It's a fun time with knowledgeable employees that will take you on a tour. You can also see some of the machinery used to crack Japanese codes and some historical attempts at codes and code-breaking. It's a fascinating place.
> I think this plays a huge part as well. My wife and I were watching an episode of the US cop show “The Rookie” and they casually discussed paying a ticket for driving SEVENTY MILES OVER THE SPEED LIMIT. I went and checked and in LA the cost is about $500. This blew my mind.
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.
> Notice how even if you are an early bird and in the office by 9, you are a lazy slacker when you leave at 5? Then someone rolls in at 11 and leaves at 7 - same number of hours. HARD WORKER.
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?
People regularly walk in from the street just in time for that 10:30 standup.
Then it's 11, then they get ready for the day, then it's lunch time. Then it's lunch coma. Then by 3PM they start gaining speed. By that time, I am already exhausted.
To be fair some people have naturally different "peak hours" and sleep schedules. I naturally fall asleep around 1-2AM and wake up at 10. Going to bed earlier involves tossing and turning for hours annoying the SO. Staying up for 36 hours to "reset" works for a couple nights before the schedule drifts back to its natural state.
I practice sleep hygiene and have tried cutting out caffeine. Conversely, there's no amount of caffeine capable of facilitating deep work before 10:30-11AM, just end up frantically clicking around articles and wishing for sleep.
Maybe these people aren't trying to game the optics, they just are naturally at their most productive from 11-7. IMHO it's awesome that your company allows that kind of flexibility (and that the morning startup is at 10:30!)
Is “peak hours” a studied phenomenon? I have always assumed it is lifestyle habits and circadian rhythm/inertia. My experience with jet lag makes me think it is the latter.
If I get in at 11 it usually means I’ve already done stuff at home, probably between 8 and 10. Getting in late doesn’t mean that they’re starting late.
People are different. I’m not a morning person and struggling through the first half of the day. Right after a lunch is when my most productive hours start.
11am is the best start time for me if I have to be on a set schedule. 10am being my wake up time. These aren't ideal personally but it is a workable compromise. Although I'd rather not have to compromise on my sleep at all.
Yeah I'm weirded out by that as well. On our platform engineering team, the "early rising" crew is usually up and working at 7 - 7:30. Some guy needed the afternoon hours for personal reasons and started working at like 6:30 for two or three months.
Personally I like to start working around 8, so I can triage the monitoring while the brain runs through the last boot processes and unit activations so I can use those (for me) very productive hours between 9 and 12.
In every tech workplace I've been, 9am start time is the early risers, and 10:30-11am is when people actually 'are online'. Maybe it's different in the consulting space.
I often treasure the ~7:30-9:30 chunk of my day when WFH because of this tendency. It's basically guaranteed focus time and always feels a pity to lose it commuting on the days I go to the office
> I’m usually ready to go full speed by 8AM, I wfh and kids are out the door to school by 7:35-7:40Am.
With somewhat younger kids (preschool), they too are out the door by 07:35-07:40, but it's me who's walking them to their facilities, which means there's no way I could possibly start working before 09:00, or before 09:30 if I don't want to start on an empty stomach.
> Also related to the ending, I‘ve come to realise more and more that most people reason out of belief first and arguments second on a lot of things (maybe most things?)
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.
I heard Shoemaker or Levy once talk about the modem on Voyager...running at a blistering 10 bps. I keep our old 2400 bps modem around as a curio. The memories are interesting and fun for me, but I get that they may not be so much for some of the other engineers I work with.
> Is it an in-built preference? I think a robust monism is still a fairly radical position, especially among religious views. For example even the branches of Christianity which tack more materially tend to draw a rigid boundary between creator/created, God/the universe, etc. (and if you interrogate lay views they tend to skew even more dualistically).
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.
One of the (maybe few) niceties of MS Office these days is that you can search through a list of most available commands through a simple Alt+Q and typing. This greatly improved my productivity for some common tasks, and it's the sort of discoverability that'd be helpful to make LibreOffice easier to use.
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.
LibreOffice has the same feature. Type Shift+Esc or go to Help > Search Commands to activate the head-up display. You can then search for the command you want.
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.