Date: Mon, 4 Sep 2023 22:34:41 +0300
On Mon, 4 Sept 2023 at 21:44, Brian Bi <bbi5291_at_[hidden]> wrote:
>> And I still don't see how that appears overestimated, but then again..
>> ..I don't really care. If it "appears" overestimated with zero facts
>> backing
>> up that appearance, whereas the estimates are based on fairly many
>> facts, and also contain some amounts of guesstimate noise, I still
>> know which
>> indication to pick, it's easy.
> The sense in which the costs of an ABI break are "overestimated" is in what Jason wrote---namely, the idea that every time an ABI break happens, the least costly option is to reimplement any binary blob that your product depends on and that is incompatible with the new ABI.
I don't recall such an argument being made. The ABI-stability concern
arguments talk about binary blobs that you can't reimplement, so while
the ABI break is there, either your product doesn't run (if you're
lucky), or runs so incorrectly that you can't ship it (if you're less
lucky).
>> And I still don't see how that appears overestimated, but then again..
>> ..I don't really care. If it "appears" overestimated with zero facts
>> backing
>> up that appearance, whereas the estimates are based on fairly many
>> facts, and also contain some amounts of guesstimate noise, I still
>> know which
>> indication to pick, it's easy.
> The sense in which the costs of an ABI break are "overestimated" is in what Jason wrote---namely, the idea that every time an ABI break happens, the least costly option is to reimplement any binary blob that your product depends on and that is incompatible with the new ABI.
I don't recall such an argument being made. The ABI-stability concern
arguments talk about binary blobs that you can't reimplement, so while
the ABI break is there, either your product doesn't run (if you're
lucky), or runs so incorrectly that you can't ship it (if you're less
lucky).
Received on 2023-09-04 19:34:54