Re: Discussion about why GNU/Linux system upgrades cause old programs to break

"Dr. Arne Babenhauserheide" <[email protected]> writes:

> The breakages due to using anotherversion of the compiler can be fixed
> by taking Hyrum's Law to heart and avoid breaking the implicit
> interface in the compiler.

I've explained this before: developers make wrongful assumptions based
on instruction selection.  If these are never to be broken, then the
compiler simply must never change the code it generates.

Do you really want that?

I do not think that's a reasonable ask, and I do not think anyone asking
for it would make the same guarantee in the same situation (because
they'd quickly find that they aren't allowed to change the compiler and
thus cease to be developers).

IMO, the opposite is the case: the "solution" to Hyrum's law is not to
respect the implicit interface, but to make it as hard as possible to
rely on the implicit interfaces.

Here's some examples of how to do that:

- Assume you provide a sorting function.  This sorting function does
  *not* guarantee stable sorting (i.e. it may change the relative order
  of elements in the same equality class).  Then, in a maintainer mode
  of some sort, the sorting function should shuffle before sorting to
  prevent users from relying on accidental stable sorting.
- In the context of a compiler, for a given undefined behaviour, make it
  crash, loudly, instead of doing something nonsensical.  (this is
  -fsanitize=undefined or -ftrapv or so on)
- Forbid and loudly diagnose every incorrect use; encode as much
  information as possible into the type system.
- Seed hash functions with something unreliable, such as a random seed
  or the process ID.

And so on.

These all boil down to a simple thing: break implicit assumptions before
they can be made.  (Even after is okay - better late than never - but it
takes more consideration then)

This isn't always possible, of course.  And it may not be desirable in
production builds for performance reasons, but it very well should be
done at least on development machines and in CI.

I say that this is a "solution" because you can almost certainly never
actually cover all the possible implicit assumptions, but this will go a
long way.

Just like you could never guarantee the entire implicit interface.

> Not all breakage can be prevented, but breakage that can be prevented
> should be prevented.

I disagree, and so does your source (the one about volatile software).
A breakage can be justified.

> This is the core tenet of the rule: do not make your software volatile.
> https://stevelosh.com/blog/2012/04/volatile-software/

The grievance of this author is also not one that is comparable to the
changes to GCC discussed here.

> The fix is The Software Maintainer's Pledge:
> https://bzg.fr/en/notes/the-software-maintainers-pledge/

Abstract pledges divorced from concrete situations can sound very
flowery.

They're also useless.

In reality, almost certainly Org-mode has had breaks that clash with
this pledge.  Doubly so if we account for all aspects of the implicit
interface.
-- 
Arsen Arsenović

-----BEGIN PGP SIGNATURE-----

iKIEARYKAEoWIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCapVDLhsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDIQHGFyc2VuQGFhcnNlbi5tZQAKCRBSwpQwHqLEk7SP
AP47UATwIw88cgAV02+flNI/DS1efkaufkwGuprOoUl7hwD/eusgFN0ew4JTGen2
CYXImGf0PCj8UxInh8HYI6BKWgM=
=obOa
-----END PGP SIGNATURE-----