Re: Time travel accident

[Simon Tournier]

Hi,

On Mon, 17 Apr 2023 at 15:16, Vagrant Cascadian 
<vagrant@reproducible-builds.org> wrote:
> On 2023-04-17, Simon Tournier wrote:

>>> My plan is to write a service that makes it easy to offload a build to a
>>> VM that runs with a different time (“in the past”) or something along
>>> these lines to mitigate the problem.

[...]

> I can see "in the past" being useful to handle builds with time-bombs
> that already slipped through the cracks

My use-case is a researcher trying to redo in the future of 5 years some
computations from a published (3 years ago) article providing some
channels.scm and manifest.scm files.

In this use-case, this researcher often runs Guix on the top of some
GNU/Linux distro and probably on some shared machine in some University.

Last, I envision for my use-case that the Guix infrastructure ecosystem
would not be there to run this “offloading service”.  Otherwise, it
appears to me far easier to just store the current substitutes – or say
part of the current substitutes.


>> Wording aside :-) What do Reproducible Builds for that?  Because
>> time-bomb seems similar as timestamp…
>
> At least for https://tests.reproducible-builds.org/debian on
> amd64/x86_64, I think one of the builds runs approximately 1 year, 1
> month and 1 day in the future (+397 days?), which pretty much maximizes
> the chance of a difference in year, month or day, while sommewhat
> minimizing detection of time bombs...

Since we are somehow building (at least) twice (Bordeaux and Berlin),
maybe we could exploit this fact and so build “in the future“.

I mean, similarly as we are doing world-rebuild with core-updates
cycles, we could do a feature branch with a different time (”in the
future“) more or less around the release.  Somehow, similarly as we are
tagging some packages with ‘non reproducible’, we could tag the ones
with ’time bombs’.

> For detecting time-bombs, I would guess you want to test even further
> into the future, maybe 5-10 years or so. Much longer, and you are
> getting pretty close to 2038, which is an extra-special set of timebombs
> that will need to be addressed at some point!

Yeah, 2038 is something [1]…

1: <https://en.wikipedia.org/wiki/Year_2038_problem>


Cheers,
simon