The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] UNESCO call for a study on the future institutional structure for Software Heritage (fwd)
@ 2020-09-10  4:16 Robert Brockway
  2020-09-10  9:33 ` Edouard Klein
  0 siblings, 1 reply; 4+ messages in thread
From: Robert Brockway @ 2020-09-10  4:16 UTC (permalink / raw)
  To: TUHS List

FYI.  UNESCO call for a study on the future institutional structure for 
Software Heritage.

---------- Forwarded message ----------
Dear all,
     I do hope you are all safe, and could take some time off to recharge the 
batteries that these hectic times have drained quite a bit.

Some of you know already Software Heritage (https://www.softwareheritage.org): 
it is a nonprofit initiative, started by Inria and supported by UNESCO, whose 
mission is to ensure that software source code, as part of the common heritage 
of humankind, is preserved over time and made available to all, building, 
maintaining and developing a universal source code archive, providing 
persistent identifiers for all software artifacts, and creating the largest 
shared knowledge base about software artifacts ever built.

This is a long term undertaking, and UNESCO has just published a call for 
advice, via a small feasibility study providing options for establishing the 
future independent, non profit, multi-stakeholder organization that will host 
Software Heritage for the long run.

As Software Heritage is a shared infrastructure that will support use cases of 
interest to the members of this list, I take the liberty to bring this call to 
your attention, and I'd be very grateful if you could also forward it to 
whomever you believe could be interested in answering.

Detailed information on the expected advice and procedures to answer the call 
is online at: 
https://careers.unesco.org/job/Paris-Consultant-on-Software-Heritage-CIMID/519826502/

The deadline for the answer is September 26th.

Thank you for your help

Roberto Di Cosmo (roberto@dicosmo.org)
_______________________________________________
foundations mailing list
foundations@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/foundations

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [TUHS] UNESCO call for a study on the future institutional structure for Software Heritage (fwd)
  2020-09-10  4:16 [TUHS] UNESCO call for a study on the future institutional structure for Software Heritage (fwd) Robert Brockway
@ 2020-09-10  9:33 ` Edouard Klein
  2020-09-13 17:42   ` Paul Winalski
  0 siblings, 1 reply; 4+ messages in thread
From: Edouard Klein @ 2020-09-10  9:33 UTC (permalink / raw)
  To: Robert Brockway; +Cc: TUHS List

Adding a bit of context, Software Heritage is used for example by GNU
Guix, which aims at making builds reproducible down to the exact bit.

Every piece of public source code used by Guix in a build will get
automatically archived by software heritage.

https://www.softwareheritage.org/2019/04/18/software-heritage-and-gnu-guix-join-forces-to-enable-long-term-reproducibility/

Given the time spent by people here trying to get things to build again,
I expect the ability of Guix to freeze and archive all dependencies and
build instructions to be of interest here:
https://guix.gnu.org/manual/en/html_node/Channels.html#Replicating-Guix

Cheers,

Edouard.

Robert Brockway writes:

> FYI.  UNESCO call for a study on the future institutional structure for Software
> Heritage.
>
> ---------- Forwarded message ----------
> Dear all,
>     I do hope you are all safe, and could take some time off to recharge the
>     batteries that these hectic times have drained quite a bit.
>
> Some of you know already Software Heritage (https://www.softwareheritage.org):
> it is a nonprofit initiative, started by Inria and supported by UNESCO, whose 
> mission is to ensure that software source code, as part of the common heritage
> of humankind, is preserved over time and made available to all, building, 
> maintaining and developing a universal source code archive, providing persistent
> identifiers for all software artifacts, and creating the largest shared
> knowledge base about software artifacts ever built.
>
> This is a long term undertaking, and UNESCO has just published a call for
> advice, via a small feasibility study providing options for establishing the 
> future independent, non profit, multi-stakeholder organization that will host
> Software Heritage for the long run.
>
> As Software Heritage is a shared infrastructure that will support use cases of
> interest to the members of this list, I take the liberty to bring this call to 
> your attention, and I'd be very grateful if you could also forward it to
> whomever you believe could be interested in answering.
>
> Detailed information on the expected advice and procedures to answer the call is
> online at:
> https://careers.unesco.org/job/Paris-Consultant-on-Software-Heritage-CIMID/519826502/
>
> The deadline for the answer is September 26th.
>
> Thank you for your help
>
> Roberto Di Cosmo (roberto@dicosmo.org)
> _______________________________________________
> foundations mailing list
> foundations@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/foundations


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [TUHS] UNESCO call for a study on the future institutional structure for Software Heritage (fwd)
  2020-09-10  9:33 ` Edouard Klein
@ 2020-09-13 17:42   ` Paul Winalski
  2020-09-14  0:33     ` John Gilmore
  0 siblings, 1 reply; 4+ messages in thread
From: Paul Winalski @ 2020-09-13 17:42 UTC (permalink / raw)
  To: Edouard Klein; +Cc: TUHS List

On 9/10/20, Edouard Klein <edouardklein@gmail.com> wrote:
> Adding a bit of context, Software Heritage is used for example by GNU
> Guix, which aims at making builds reproducible down to the exact bit.
>
To get complete build reproducibility, your compiler writers have to
be careful.  It's very easy to introduce random variability that
doesn't affect the performance or semantics of the program.  Register
choice and instruction ordering, for example.  Here's a real-world
example of how such things can happen.  Compilers have lots of data
structures (temporary variables, for example) that require unique
identifiers, but the value of the identifier is irrelevant--it simply
has to be unique.  It's tempting to use the memory address of the data
structure as the unique ID--it saves both space and time.  But suppose
that your register allocator has to index those items in a hash table,
and also at some point sequentially walks the hash table.  The order
of the sequential walk is now dependent on the memory addresses of the
items in the table.  In the case I observed, this resulted in
different register choices if the program was recompiled.

-Paul W.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [TUHS] UNESCO call for a study on the future institutional structure for Software Heritage (fwd)
  2020-09-13 17:42   ` Paul Winalski
@ 2020-09-14  0:33     ` John Gilmore
  0 siblings, 0 replies; 4+ messages in thread
From: John Gilmore @ 2020-09-14  0:33 UTC (permalink / raw)
  To: Paul Winalski; +Cc: TUHS List

Paul Winalski <paul.winalski@gmail.com> wrote:
> To get complete build reproducibility, your compiler writers have to
> be careful.  It's very easy to introduce random variability that
> doesn't affect the performance or semantics of the program.

The GNU compilers are already tested for complete reproducibility.  We
at Cygnus Support built that infrastructure back in the 1990s, when we
made gcc into a cross-compiler (compiling on any architecture + OS,
targeting any other).  We built the Deja Gnu test harness, and some
compiler/assembler/linker test suites, that rebuilt not just our own
tools, but also a test suite with hundreds or thousands of programs.  We
compared their binaries until they were bit-for-bit identical when built
on many different host machines of different architectures.

To make it work, we had to fix many bugs and misfeatures, including even
some high-level design bugs, like object file formats that demanded a
timestamp (we decided that 0 was a fine timestamp).  A few of those bugs
involved generating different but working instruction sequences -- I
recall fixing one that depended on an uninitialized local variable.

I have not been involved in the release process for gcc or other GNU
tools for many years, but I believe that these tests are still in use --
because the maintainers care.  If *your* compiler isn't reproducible,
why not switch to a free software one that is?

The Reproducible Builds effort is standing on the shoulders of many
others who came before, and who value deterministic computer behavior
and access to the matching source code of the binaries that users
depend upon.

	John Gilmore
	

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-09-14  0:34 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-10  4:16 [TUHS] UNESCO call for a study on the future institutional structure for Software Heritage (fwd) Robert Brockway
2020-09-10  9:33 ` Edouard Klein
2020-09-13 17:42   ` Paul Winalski
2020-09-14  0:33     ` John Gilmore

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ http://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index tuhs

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git