rewriting history; Was: Concerns/questions around Software Heritage Archive

[Attila Lendvai]

> I was also distressed to see how poorly they treated a developer
> who wished to update their name:
> https://cohost.org/arborelia/post/4968198-the-software-heritag
> https://cohost.org/arborelia/post/5052044-the-software-heritag


let's put aside the trans aspect of this question for a moment, because this 
question has broad implications, much broader than the regrettable struggles of 
trans people.

the question here is whether person A has the right to demand that others 
change their memory of A's past actions (i.e. rewrite history, or else become a 
felon... or maybe just unwelcome in polite society?).

so, let's just assume that i have decided to prefer being called a new name 
(without disclosing my reasons).

is it reasonable for me to demand from somebody else to change their memory of 
my past actions? e.g. to demand that they rewrite their memory/instances of my 
books that i have published under my previous name in the past? or that they 
forget my old name, and when the change happened? or that they do not link the 
two names to the same individual?

if so, then where is the line? what's the principle here? and what are its 
implications?

do i have the right to demand the replacement of a page in each copy that 
exists out there? i.e. should it be criminal (or just a sin?) to own old 
copies? do i have the right to demand that certain libraries must sell/burn 
their copies of my books and never own them again?

what if i committed a fraud? e.g. i pushed a backdoor somewhere... do i have 
the right to memory-hole my old identity?

and who will enforce such a right? the government? i.e. those people who 
already keep an (extralegal) record of whenever i farted in the past decade? 
where can i even file my GDPR request for that? would that really be a "right 
to be forgotten", or merely a tool of even tighter monopolization of The 
Central Database?

what if i'm a joker and i demand a new change every week for the rest of my 
life? do i have the right to the resources of every library out there? to keep 
their staff and computers busy for the next couple of decades?

but let's put the technical aspects aside; wherever we draw the line... what 
are the implications of that for borader society? because i sure see some 
actors out there who can hardly wait to start erasing certain records at the 
barrel of the law, including rewriting books of significance... (and while we 
are at it, i suggest to start preserving your offline/local copies, because 
we're up to a wild ride!)

humanity has reached an enormous challenge with the complete marginalization of 
the costs of storing and transmitting information. it's a completely 
new/different playing field, and how we proceed from here has grave 
implications. this questions is nowhere near as obvious/trivial as presented in 
the cited blog post.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“It is only when compassion is present that people allow themselves to see the 
truth. […] Compassion is a kind of healing agent that helps us tolerate the 
hurt of seeing the truth.”
— A.H. Almaas (1944–), 'Elements of the Real in Man (Diamond Heart, 
Book 1)'

Re: Concerns/questions around Software Heritage Archive

[Attila Lendvai]

> only a 35 yrs old white cis boy

you're judging a group of individuals, namely those who were handed the cis 
white male mix at the genetic lottery, as a uniform blob. and maybe even 
somewhat deplorable, if i'm reading your right.

does it make sense to judge an individual based on some coincidental 
properties? or really, based on anything else than their actions? does it make 
sense to discuss the actions/morality of a group of individuals that is formed 
based on some coincidental properties? e.g. what can we say about the morality 
of all the blond people?

and ultimately, is that an effective way of speaking up for human rights and 
welcoming environments -- of all things?

maybe it's time to take a thorough look at the book that you're preaching from?

if i may, let me attempt to inspire you:

“The world is changed by your example, not by your opinion.”
— Paulo Coelho (1947–)
%
“Yesterday I was clever, so I wanted to change the world. Today I am wise, so I 
am changing myself.”
— Rumi (1207–1273)
%
“If there is to be peace in the world,
There must be peace in the nations.
If there is to be peace in the nations,
There must be peace in the cities.
If there is to be peace in the cities,
There must be peace between neighbors.
If there is to be peace between neighbors,
There must be peace in the home.
If there is to be peace in the home,
There must be peace in the heart.”
— Lao Tzu (sixth century BC)
%
“A man of humanity is one who, in seeking to establish himself, finds a 
foothold for others and who, in desiring attaining himself, helps others to 
attain.”
— Confucius (551–479 BC)
%
“To put the world in order, we must first put the nation in order; to put the 
nation in order, we must first put the family in order; to put the family in 
order; we must first cultivate our personal life; we must first set our hearts 
right.”
— Confucius (551–479 BC)
%
“Until we have met the monsters in ourselves, we keep trying to slay them in 
the outer world. And we find that we cannot. For all darkness in the world 
stems from darkness in the heart. And it is there that we must do our work.”
— Marianne Williamson (1952–), 'Everyday Grace: Having Hope, Finding 
Forgiveness And Making Miracles' (2004)
%
“If things go wrong in the world, this is because something is wrong with the 
individual, because something is wrong with me. Therefore, if I am sensible, I 
shall put myself right first”
— Carl Jung (1875–1961), 'The Meaning of Psychology for Modern Man'

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“If liberty means anything at all, it means the right to tell people what they 
do not want to hear.”
— George Orwell (1903–1950)

Re: Guix days guix home discussion

[Ludovic Courtès]

Ryan Prior  skribis:

> On Sunday, March 17th, 2024 at 12:24 PM, Ludovic Courtès  wrote:
>
>> ‘guix home import’ does exactly that: generate a first configuration
>> that you may find necessary to tweak. Perhaps the manual should clarify
>> that?
>
> Maybe we should call it "guix home init" then? Describing it as "import" 
> implies to me that a situation where relevant config is not imported would be 
> seen as a bug, or at least as a potential site for improvement.

Yes, maybe, though it would be very different from ‘guix system init’,
which could be a source of confusion.

It would also be nice for it to recognize more config files, but it
doesn’t have to cover “everything” IMO.

Ludo’.

Re: Guix days guix home discussion

[Ludovic Courtès]

Hello!

Ryan Prior  skribis:

> 1. I haven't been able to use Guix Home to migrate my home config across 
> machines. I've done this 3 times since I started using Guix on what I would 
> consider advanced-level (writing Guile, defining my own packages & manifests, 
> contributing patches.) Each time, I've got frustrated with the applicability 
> of what documentation or examples I could find, and ended up migrating the 
> bad old way by copying config files & modifying them as needed. Guix does 
> help me in these migrations somewhat by allowing me to install needed 
> software environments in a non-disruptive way, but I haven't gotten any use 
> out of Home here. For reference, my attempts have been on elementary OS and 
> Ubuntu, never on Guix System.

If this is a documentation issue, it would be nice to pinpoint what
examples were missing or what info was unclear.

If it’s a more general applicability issue (like: “this thing is useless
to me”), then maybe that’s okay :-), or maybe we should look which or
your use cases should be addressed by Home but aren’t.

> 2. I've desired to use Guix Home on foreign distros to run Guix services 
> (like Docker or Postgres) via Shepherd, but have failed to do so thus far. I 
> read documentation in Guix and Shepherd, and some source code. I've got 
> Shepherd installed & running on some of my machines, but I can't figure out 
> how to use it to run Guix services. Possibly I'm missing something, but I 
> also wonder whether perhaps Guix services are only intended to run on Guix 
> System?

In general, you can only use services that are explicitly designed for
or “ported” to Guix Home, which are documented here:

  https://guix.gnu.org/manual/devel/en/html_node/Home-Services.html

(You can find them with ‘guix home search’.)

Now, there’s a mechanism in place that simplifies porting System
services to Home, though again, that work has to be done explicitly.

> I would like to help make Guix Home & services have an excellent experience 
> on foreign distros. I intend to write documentation, blog posts and code to 
> do so. I've been stuck, though, in actually making progress understanding how 
> to accomplish my aims, and every time I've tried it so far I've been in 
> enough of a hurry that I gave up after a couple days' hacking. If anybody 
> wants to pair with me or lend a hand I'd be thrilled to get back to this.

Would be great!

Thanks,
Ludo’.

Re: Concerns/questions around Software Heritage Archive

[Richard Sent]

Regarding Guix development, if the decision is made to not change
existing policy or implement another authorship mechanism, I think some
text could be added to the manual explaining such.

Contributing to Guix is an intentional thing, unlike SWH. Updating the
manual means contributors will, at least, be making an informed decision
to contribute, knowing that names cannot be changed in the Guix repo's
history due to X, Y, and Z consequences in Guix's functionality.

I'm not suggesting that this solution is "the end-all-be-all" or
invalidates alternative avenues, but I feel it is an improvement over
the status quo with no negative tradeoffs. I would not support a
solution that obsoletes time-machine or requires regular manual
intervention during upgrades.

Personally as a new contributor I find it gratifying to see my name in
the commit history.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

Re: Proposal to turn off AOT in clojure-build-system

[Jean-Pierre De Jesus Diaz]

Hello,

>Correctly handling the ABI concerns — which Guix currently does
>not do — would result in a combinatorial explosion of Clojure
>packages should multiple versions of Clojure ever be available in
>Guix at the same time.

I think this is partly true and also a problem of other languages in
Guix too but it is solvable IMO, one does need indeed to duplicate
each and every package for the specific Clojure version used but
that can be solved by writing a procedure with PACKAGE-MAPPING
that changes `#:clojure' argument recursively for the package inputs,
just like it is done with PACKAGE-WITH-PYTHON2, thus using one line
of code to change a lot of packages.

I don't know much of Clojure to have an opinion on it but just saying
how that problem is and should be solved because it could also affect
packages for a potential new Rust build system since ABI compatibility
is a problem too.

Re: Concerns/questions around Software Heritage Archive

[Ludovic Courtès]

Hi,

Ian Eure  skribis:

> They appear to be using the archive to build LLMs:
> https://www.softwareheritage.org/2024/02/28/responsible-ai-with-starcoder2/

To me, if the end result is that copyleft licenses are ignored, as is
the case with Microsoft’s CoPilot, then we have a problem.

That’s no excuse, but the problem goes beyond SWH: people upload copies
of repositories to GitHub without one’s consent (nothing to blame them
for, it’s free software), and then code ends up being used as training
data for CoPilot.

As you may have seen, this is being discussed on the Fediverse.  I’d
like to leave the SWH people time to reply to concerns that have been
raised.

> I was also distressed to see how poorly they treated a developer who
> wished to update their name:
> https://cohost.org/arborelia/post/4968198-the-software-heritag
> https://cohost.org/arborelia/post/5052044-the-software-heritag

That’s another concern, with append-only storage in general, starting
with Git.  We should look for solutions that work for both contributors
who change names and for users.  This has happened several times in Guix
and what people did was search/replace their name and adjust ‘.mailmap’.

Thanks,
Ludo’.

Re: Guix days guix home discussion

[Ryan Prior]

On Sunday, March 17th, 2024 at 12:24 PM, Ludovic Courtès  wrote:

> ‘guix home import’ does exactly that: generate a first configuration
> that you may find necessary to tweak. Perhaps the manual should clarify
> that?

Maybe we should call it "guix home init" then? Describing it as "import" 
implies to me that a situation where relevant config is not imported would be 
seen as a bug, or at least as a potential site for improvement.

Re: Guix days guix home discussion

[Ryan Prior]

On Sunday, March 17th, 2024 at 12:24 PM, Ludovic Courtès  wrote:

> I personally try to lower the barrier for Home services, but I think few
> people (if any) beyond me review Home services.
> 
> We should expand the ‘home’ team; who’s in?

I would like to contribute to Guix home, but haven't been able to get much use 
out of it myself. This is a combination of two frustrations I've hit:

1. I haven't been able to use Guix Home to migrate my home config across 
machines. I've done this 3 times since I started using Guix on what I would 
consider advanced-level (writing Guile, defining my own packages & manifests, 
contributing patches.) Each time, I've got frustrated with the applicability of 
what documentation or examples I could find, and ended up migrating the bad old 
way by copying config files & modifying them as needed. Guix does help me in 
these migrations somewhat by allowing me to install needed software 
environments in a non-disruptive way, but I haven't gotten any use out of Home 
here. For reference, my attempts have been on elementary OS and Ubuntu, never 
on Guix System.

2. I've desired to use Guix Home on foreign distros to run Guix services (like 
Docker or Postgres) via Shepherd, but have failed to do so thus far. I read 
documentation in Guix and Shepherd, and some source code. I've got Shepherd 
installed & running on some of my machines, but I can't figure out how to use 
it to run Guix services. Possibly I'm missing something, but I also wonder 
whether perhaps Guix services are only intended to run on Guix System?

I would like to help make Guix Home & services have an excellent experience on 
foreign distros. I intend to write documentation, blog posts and code to do so. 
I've been stuck, though, in actually making progress understanding how to 
accomplish my aims, and every time I've tried it so far I've been in enough of 
a hurry that I gave up after a couple days' hacking. If anybody wants to pair 
with me or lend a hand I'd be thrilled to get back to this.

Ryan

Re: cmake-build-system: build tests only if #:tests? is true?

[Ludovic Courtès]

Hi,

Hartmut Goebel  skribis:

>> I will submit a patchset shortly for review and if accepted we can
>> look to combine all the cmake patches for the large rebuild.
>
> Yes, of course we should combine them. May I ask you to take care of
> it and include mine, which I just posted:
>
> https://issues.guix.gnu.org/issue/69554

Also, isn’t ‘BUILD_TESTING’ a convention rather than a flag CMake always
honors?

Ludo’.

Re: doc: installation: fix ~root confusion (was Re: doc: Removing much of Binary Installation)

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> Otherwise LGTM.  Could you send another diff?  Would a commit message
> like this be okay:
>
> doc: Simplify installation instructions.
>
> * doc/guix.texi (Installation): Direct readers towards the installation
> script.  Remove superfluous commentary.

I’d recommend sending it to guix-patches to make it more visible.

Ludo’.

Re: Building container images with nix2container

[Antoine Eiche]

Simon Tournier  writes:

>> Well, I have not followed on which strategy Guix relies.  What is the
>> one of nix2container?  The one described here:
>>
>> https://grahamc.com/blog/nix-and-layered-docker-images/
>
> To answer to my question, the way to build the container image is
> different, hence it does not make much sense to speak about a
> “strategy“. :-)

nix2container actually uses this strategy. To build an image,
nix2container builds several derivations. Each of these derivation
contains a set of layers. The layers of each set are determined by using
the algorithm mentionned above. At runtime, all of these derivations are
packed to build the final image.

> However, the blog post says:
>
> To address this issue, we could add a nonReproducible option in
> the containerTools.buildLayer function. Instead of only storing
> the digest, we would also store the tar. Note in practice, an
> important part of nixpkgs is bit reproducible and this would
> rarely be needed.
>
> And so the question is how do you know beforehand if the flag
> ’nonReproducible’ must be applied or not?

Sorry, i have missed your mails:/ So, here is the answer I provided on
Mastodon few days ago.

Generally, i don't think it's possible to know when this flag is needed
before encountering an issue at image push time: Skopeo would then say
layer hashes mismatch.

However, in practice, it seems this flag is not often used.
To hit this issue, I think you need to substitute the JSON file from a
binary cache while building non bit reproducible store paths locally. In
this case, the hash specified in the JSON file could be different from
the hash of the derivation locally built. But, the locally built store
path is a dependency of the JSON file, they should also be in the binary
cache and would generally also be substituted.
I admit this is not rock-solid science... but it seems to make the job
in practice. And if it occurs, a strategy could be to isolate this
storepath into a layer with the non-reproducible flag.

There is also another option which is currently used by
nixpkgs.dockerTools.streamLayeredImage. To avoid the reproducibility
issue while still avoiding writing layer tarballs, we could introduce
another option to let nix2container generating the layer hashes on the
fly, just before pushing the image. This would then require more IOs
since nix2container would need to read layer store paths on each image
push.

> Indeed, the approach of nix2container could be helpful in addition to
> ‘guix pack’.  Maybe an extension… :-)

>From my point of view, another advantage of the nix2container
approach is to delegate a important part of the build image mecanism
to Skopeo, a tool well maintained and used by a lot of people.

lewo.

Re: binfmt_misc

[Ludovic Courtès]

Hi,

Z572 <873216...@qq.com> skribis:

> see
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=21ca59b365c0
>
> linux 6.7 support use binfmt_misc to add new binary formats within
> unprivileged namespaces,
> I think this improves guix reproducibility and also avoids leakage of
> the host's binfmt into the compilation environment, improves the
> cross-compilation environment, and potentially unlocks more features,
> such as not having to system-configure qemu-binfmt, running x86-64
> software on a riscv64 machine using `guix pack', guix shell -C -s
> riscv64-linux, etc.

Interesting.  Avoiding leakage looks like the main benefit to me
(currently, one has to ‘herd stop qemu-binfmt‘ to ensure there’s no
leakage).

I’m not sure how it helps with the features you mention, though?

Thanks for the heads-up,
Ludo’.

Re: Guix days guix home discussion

[Ludovic Courtès]

Hi!

Gábor Boskovits  skribis:

> 1. It is rare that guix home import does the right thing (it is usually
> removing some startup file customizations, does not seem to arrange to pick
> up profiles, not even its own). Either we should improve it, or document
> that it only gives a skeleton configuration and add some guidance on the
> steps needed to get a working one.

‘guix home import’ does exactly that: generate a first configuration
that you may find necessary to tweak.  Perhaps the manual should clarify
that?

I’m not sure what you mean though when you say it rarely does the right
thing.  Did you discuss examples?

> 2. The user default profile and the home package profile being separate is
> causing some issues. It might be enough to document all the special
> profiles somewhere (which as of now include at least system profile, user
> profile, pull profile and home profile), but we can also think about a bit
> more general solution, along the lines of a home service that ensures that
> a given profile matches the supplied manifest, and have variables for the
> special profiles. (These could then provide extensions to the shell
> services which could arrange to pick them up)

Likewise, would be nice to see if there are specific examples of
problems that people stumble upon.

> 3. Sometime on home reconfigure the shell prompt customizations seem to get
> lost. Sourcing the shell startup file fixes it. I will have to look into
> this more to file a proper bug report.
> 4. Creating a guix development environment service would be beneficial, to
> showcase the possibilities and to simplify onboarding. On top of there
> could be an additional service that adds emacs integration to this
> development environment.

Interesting, I like that.

(A colleague of mine has been working on a pre-configured Emacs
targeting developers using Guix and writing C/C++/Fortran and LaTeX:
.)

> 5. There was a recommendation to relax the expectations on the home
> services merged. Right now a lot of people are just writing services for
> private use. Most probably such a single usecase service would already be
> beneficial to multiple people. The idea is the following: make it easy for
> an initial home service to be merged. (Example: do not ask to implement
> options that the submitter is not using). Then take care that if there is
> an addition to the service that it really gets merged with what we already
> have. This needs a bit of up front design, we have to make sure that the
> services can be extended while maintaining backwards compatibility.

I personally try to lower the barrier for Home services, but I think few
people (if any) beyond me review Home services.

We should expand the ‘home’ team; who’s in?

Thanks for the feedback,
Ludo’.

Re: Building container images with nix2container

[Antoine Eiche]

Simon Tournier  writes:

>> Does your built images contains several layers?
>
> This had recently been introduced.
>
> 0cf75c9b2f23869201144917cea7f6ad49683d3d
> AuthorDate: Tue Dec 26 03:54:12 2023 +0300
> CommitDate: Mon Jan 8 21:04:44 2024 +0300

Thanks.

>> nix2container uses an heuristic to group store paths into layers. The
>> goal is to share common layers between images and to avoid full image
>> rebuild when only a storepath differs.
>
> Well, I have not followed on which strategy Guix relies.  What is the
> one of nix2container?  The one described here:
>
> https://grahamc.com/blog/nix-and-layered-docker-images/

Yes.
But I think it could be improved by taking the nar size into account.

lewo.

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/17/24 18:20, Ian Eure wrote:



MSavoritias  writes:


On 3/17/24 11:39, Lars-Dominik Braun wrote:

Hey,


I have heard folks in the Guix maintenance sphere claim that we

never rewrite git history in Guix, as a matter of policy. I believe
we should revisit that policy (is it actually written anywhere?)
with an eye towards possible exceptions, and develop a mechanism for
securely maintaining continuity of Guix installations after history
has been rewritten so that we maintain this as a technical
possibility in the future, even if we should choose to use it
sparingly.
the fallout of rewriting Guix’ git history would be devastating. It
would break every single Guix installation, because

a) `guix pull` authenticates commits and we might lose our trust anchor
if we rewrite history earlier than the introduction of this feature,
b) `guix pull` outright rejects changes to the commit history to 
prevent

downgrade attacks.

Additionally it would break every single existing usage of the
time machine and thereby completely defeat the goal of providing
reproducible software environments since the commit hash is used to
identify the point in time to jump to.

I doubt developing “mechanisms” – whatever they look like – would
be worth the effort. Our contributors matter, but so do our users. 
Never
ever rewriting our git history is a tradeoff we should make for our 
users.


Lars



Thats a good point. in the sense that its a tradeoff here and I
absolutely agree.


But let me add some food for thought here:

1. Were the social aspects considered when the system came into place?

2. Is it more important for the system to stay as is than to welcome
new contributors?

3. You mention "its a tradeoff we should make for our users". How many
trans people where involved in that decision and how much did their
opinion matter in this?


I am saying this because giving power to people(what is called users)
is not only handling them code or make sure everything is free
software.

Its also the hard part of making sure the voices of people that can
not code is heard and is participating and taking in mind.



Just want to say that I appreciate and agree with your thoughtful words.

I’d also note that name changes aren’t a concern limited to trans 
people, and framing this as "we have to upend everything Because 
Transgender" is both wrong and feels pretty bad to me.  Anyone can 
change their name at any time for any reason, or no reason at all, and 
may wish to update historical references to their previous names.  
Having a mechanism to support this is, in my view, a matter of basic 
decency and respect for all humans.


Thanks,

 — Ian


You are right. I failed to see how it could be desirable for other 
people too.


I agree it should be done for everybody.


MSavoritias

Re: Concerns/questions around Software Heritage Archive

[Ian Eure]

MSavoritias  writes:


On 3/17/24 13:53, paul wrote:

Hi all ,

thank you MSavoritias for bringing up points that many of us
share. It's clearly a tradeoff what to do about the past. For 
the
future, as Christpher already stated, we need a serious 
solution
that we can uphold as a free software project that does not 
alienate

users or contributors.

My opinion is that names are just wrong to be included, not 
only
because of deadnames, but in general having a database with a 
column
first_name and a column second_name is something only a 35 yrs 
old

white cis boy could have thought was a good idea to model the
spectrum of names humans use all over the world:

https://web.archive.org/web/20240317114846/https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
If we'd really need to identify contributors, and obviously 
Guix
doesn't, we could use an UUID/machine readable identifier which 
can
then be mapped to a displayed name. I believe git can already 
be

configured to do so.


giacomo



The uuid sounds like a very interesting solution indeed.

I wonder how easy it could be to add it to git.



This also seems like interesting territory to explore.  The 
concerns raised around rewriting history have valid points; I 
think it’s impractical to rewrite history any time a change needs 
to happen, as that would be an ongoing source of disruption.  But 
rewriting history *once*, to switch to a more general mechanism, 
seems like a reasonable trade to me.  This also presents an 
opportunity: we could combine this with a default branch switch 
from master to main.  A news entry left as the final commit in 
master could inform people of whatever steps may be needed to 
update (if that can’t be automated), and the main branch would 
contain the rewritten history.


It’s certainly not a perfect solution, but it seems pragmatic.

 — Ian

Re: Concerns/questions around Software Heritage Archive

[Ian Eure]

MSavoritias  writes:


On 3/17/24 11:39, Lars-Dominik Braun wrote:

Hey,

I have heard folks in the Guix maintenance sphere claim that 
we
never rewrite git history in Guix, as a matter of policy. I 
believe
we should revisit that policy (is it actually written 
anywhere?)
with an eye towards possible exceptions, and develop a 
mechanism for
securely maintaining continuity of Guix installations after 
history

has been rewritten so that we maintain this as a technical
possibility in the future, even if we should choose to use it
sparingly.
the fallout of rewriting Guix’ git history would be 
devastating. It

would break every single Guix installation, because

a) `guix pull` authenticates commits and we might lose our 
trust anchor
if we rewrite history earlier than the introduction of this 
feature,
b) `guix pull` outright rejects changes to the commit history 
to prevent

downgrade attacks.

Additionally it would break every single existing usage of the
time machine and thereby completely defeat the goal of 
providing
reproducible software environments since the commit hash is 
used to

identify the point in time to jump to.

I doubt developing “mechanisms” – whatever they look like – 
would
be worth the effort. Our contributors matter, but so do our 
users. Never
ever rewriting our git history is a tradeoff we should make for 
our users.


Lars



Thats a good point. in the sense that its a tradeoff here and I
absolutely agree.


But let me add some food for thought here:

1. Were the social aspects considered when the system came into 
place?


2. Is it more important for the system to stay as is than to 
welcome

new contributors?

3. You mention "its a tradeoff we should make for our 
users". How many
trans people where involved in that decision and how much did 
their

opinion matter in this?


I am saying this because giving power to people(what is called 
users)

is not only handling them code or make sure everything is free
software.

Its also the hard part of making sure the voices of people that 
can

not code is heard and is participating and taking in mind.



Just want to say that I appreciate and agree with your thoughtful 
words.


I’d also note that name changes aren’t a concern limited to trans 
people, and framing this as "we have to upend everything Because 
Transgender" is both wrong and feels pretty bad to me.  Anyone can 
change their name at any time for any reason, or no reason at all, 
and may wish to update historical references to their previous 
names.  Having a mechanism to support this is, in my view, a 
matter of basic decency and respect for all humans.


Thanks,

 — Ian

Re: Concerns/questions around Software Heritage Archive

[Olivier Dion]

On Sat, 16 Mar 2024, Ian Eure  wrote:

[...]

> GPL’d software I’ve created has been packaged for Guix, which I assume
> means it’s been included in SWH.  While I’m dealing with their (IMO:
> unethical) opt-out process, I likely also need to stop new copies from
> being uploaded again in the future.

Even without Guix, SWH could upload your projects into their "database".
In fact, I believe anyone can ask to archive your project to SWH.  So
even if you ask Guix to not do the archiving, anyone contributing might
change that in the future.

I believe that preventing Guix from archiving your software is a
symbolic standpoint -- which I respect --, but would put more burden on
the Guix developers.  On the other hand, if enough people refuse to
archive to SWH, this might shift Guix onto a new direction for longterm
source archiving.

I'm not a lawyer, but perhaps a first solution -- for the AI stuff --
would be to add an exception to the GPL that prevents AI from training
on it.  Alas, as usual, our legislators are late on that matter, so that
might not even work.

[...]

-- 
Olivier Dion
oldiob.ca

Re: Concerns/questions around Software Heritage Archive

[Tomas Volf]

On 2024-03-17 12:53:54 +0100, paul wrote:
> only a 35 yrs old white cis boy

Could you stop labeling people like this?  It makes me feel uncomfortable and
not welcomed...

T.

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

Re: qa.guix.gnu.org: Returns a plain Guile error for a merged issue

[Christopher Baines]

"Artyom V. Poptsov"  writes:

> Hello,
>
> I just found out that Guix QA returns a plain Guile error message when I
> try to open an issue that was merged:
>   https://qa.guix.gnu.org/issue/69654
>
> The error looks like this:
>
> An error occurred
>
> Sorry about that!
> wrong-type-arg
>
> #fWrong type to apply: ~S#f#f
>
> Please find a screenshot of the error attached.
>
> I suppose that the service should return something more meaningful than
> that.

I think this was happening because QA had problems talking to Mumi
(issues.guix.gnu.org). That's now resolved and it's back to the still
not very useful "Issue not found" message.


signature.asc
Description: PGP signature

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/17/24 13:53, paul wrote:

Hi all ,

thank you MSavoritias for bringing up points that many of us share. 
It's clearly a tradeoff what to do about the past. For the future, as 
Christpher already stated, we need a serious solution that we can 
uphold as a free software project that does not alienate users or 
contributors.


My opinion is that names are just wrong to be included, not only 
because of deadnames, but in general having a database with a column 
first_name and a column second_name is something only a 35 yrs old 
white cis boy could have thought was a good idea to model the spectrum 
of names humans use all over the world:


https://web.archive.org/web/20240317114846/https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ 



If we'd really need to identify contributors, and obviously Guix 
doesn't, we could use an UUID/machine readable identifier which can 
then be mapped to a displayed name. I believe git can already be 
configured to do so.



giacomo



The uuid sounds like a very interesting solution indeed.

I wonder how easy it could be to add it to git.


I agree that making some rules about names that are going to be wrong at 
some point or in some place is the wrong solution long term for sure.



MSavoritias

Re: Concerns/questions around Software Heritage Archive

[paul]

Hi all ,

thank you MSavoritias for bringing up points that many of us share. It's 
clearly a tradeoff what to do about the past. For the future, as 
Christpher already stated, we need a serious solution that we can uphold 
as a free software project that does not alienate users or contributors.


My opinion is that names are just wrong to be included, not only because 
of deadnames, but in general having a database with a column first_name 
and a column second_name is something only a 35 yrs old white cis boy 
could have thought was a good idea to model the spectrum of names humans 
use all over the world:


https://web.archive.org/web/20240317114846/https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

If we'd really need to identify contributors, and obviously Guix 
doesn't, we could use an UUID/machine readable identifier which can then 
be mapped to a displayed name. I believe git can already be configured 
to do so.



giacomo

Re: Error handling when 'guix substitute' dies

[Ekaitz Zarraga]

Hi Ada,

On 2024-03-17 07:18, Ada Stevenson wrote:

Hi Guix,

I have this gripe with usability regarding using substitutes.

Sometimes, usually when I'm on an enterprise network like my 
university's of library's wifi, the `guix substitute` process dies with 
a "TLS error in procedure 'write_to_session_record_port': Error in the 
push function" error message. My connection is rock-solid otherwise, and 
sometimes it doesn't happen at all.


I'm not sure if this is a fault in the actual Guix code, or there's some 
Guile library somewhere that has this bug. Anyway, I think it would be a 
useful feature to have a way to automatically restart the `guix 
substitute` process or otherwise recover from this error. Some sort of 
`--restart=no.restarts.permitted` flag. Whenever I'm updating my system 
I tend to leave and do something else, and when this happens I come back 
and nothing's actually been done, and the error is transient so I don't 
gain anything from seeing this message.


I workaround could potentially be wrapping `guix upgrade` and the like 
in a script that keeps on restarting the commands until they exit with 
0. This seems a little clunky and fragile, especially if there's an 
actually fatal error, eg. my config is not valid.


What do you guys think? Would this be something that people would be 
interested in? Or would it be better to try and find out why there's 
these transient errors (a way more time-consuming effort, I fear). Does 
anyone else have this issue?


Warmly,

Ada


Yes. I do have this error in the most inconvenient moments.
This is, if I'm not mistaken, a connection error. It has been randomly 
happening for long time (months?).


We should do something about this, probably handling the case a little 
bit better to at least give the user useful information about what 
happened to be wrong. Or take a look to the substitute servers, I think 
they are the problem, more than the users' guix code.


Rerunning things, sometimes several times, finally happens to work, but 
yes, this is very annoying.


Cheers,
Ekaitz

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/17/24 11:39, Lars-Dominik Braun wrote:

Hey,


I have heard folks in the Guix maintenance sphere claim that we never rewrite 
git history in Guix, as a matter of policy. I believe we should revisit that 
policy (is it actually written anywhere?) with an eye towards possible 
exceptions, and develop a mechanism for securely maintaining continuity of Guix 
installations after history has been rewritten so that we maintain this as a 
technical possibility in the future, even if we should choose to use it 
sparingly.

the fallout of rewriting Guix’ git history would be devastating. It
would break every single Guix installation, because

a) `guix pull` authenticates commits and we might lose our trust anchor
if we rewrite history earlier than the introduction of this feature,
b) `guix pull` outright rejects changes to the commit history to prevent
downgrade attacks.

Additionally it would break every single existing usage of the
time machine and thereby completely defeat the goal of providing
reproducible software environments since the commit hash is used to
identify the point in time to jump to.

I doubt developing “mechanisms” – whatever they look like – would
be worth the effort. Our contributors matter, but so do our users. Never
ever rewriting our git history is a tradeoff we should make for our users.

Lars


Thats a good point. in the sense that its a tradeoff here and I 
absolutely agree.



But let me add some food for thought here:

1. Were the social aspects considered when the system came into place?

2. Is it more important for the system to stay as is than to welcome new 
contributors?


3. You mention "its a tradeoff we should make for our users". How many 
trans people where involved in that decision and how much did their 
opinion matter in this?



I am saying this because giving power to people(what is called users) is 
not only handling them code or make sure everything is free software.


Its also the hard part of making sure the voices of people that can not 
code is heard and is participating and taking in mind.


I am not trying to say what we should do about commit history rewriting 
here. Personally the tradeoffs are probably worth it.


But I am trying to say what Guix should do as a culture over including 
people or excluding in the case of Software Heritage.



MSavoritias

Re: Concerns/questions around Software Heritage Archive

[Lars-Dominik Braun]

Hey,

> I have heard folks in the Guix maintenance sphere claim that we never rewrite 
> git history in Guix, as a matter of policy. I believe we should revisit that 
> policy (is it actually written anywhere?) with an eye towards possible 
> exceptions, and develop a mechanism for securely maintaining continuity of 
> Guix installations after history has been rewritten so that we maintain this 
> as a technical possibility in the future, even if we should choose to use it 
> sparingly.

the fallout of rewriting Guix’ git history would be devastating. It
would break every single Guix installation, because

a) `guix pull` authenticates commits and we might lose our trust anchor
if we rewrite history earlier than the introduction of this feature,
b) `guix pull` outright rejects changes to the commit history to prevent
downgrade attacks.

Additionally it would break every single existing usage of the
time machine and thereby completely defeat the goal of providing
reproducible software environments since the commit hash is used to
identify the point in time to jump to.

I doubt developing “mechanisms” – whatever they look like – would
be worth the effort. Our contributors matter, but so do our users. Never
ever rewriting our git history is a tradeoff we should make for our users.

Lars

qa.guix.gnu.org: Returns a plain Guile error for a merged issue

[Artyom V. Poptsov]

Hello,

I just found out that Guix QA returns a plain Guile error message when I
try to open an issue that was merged:
  https://qa.guix.gnu.org/issue/69654

The error looks like this:
--8<---cut here---start->8---
An error occurred

Sorry about that!
wrong-type-arg

#fWrong type to apply: ~S#f#f
--8<---cut here---end--->8---

Please find a screenshot of the error attached.

I suppose that the service should return something more meaningful than
that.

Thanks,
- avp


-- 
Artyom "avp" Poptsov 
Home page: https://memory-heap.org/~avp/
CADR Hackerspace co-founder: https://cadrspace.ru/
GPG: D0C2 EAC1 3310 822D 98DE  B57C E9C5 A2D9 0898 A02F


signature.asc
Description: PGP signature

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/16/24 21:45, Tomas Volf wrote:

On 2024-03-16 20:24:50 +0200, MSavoritias wrote:

I was also distressed to see how poorly they treated a developer who
wished to update their name:
https://cohost.org/arborelia/post/4968198-the-software-heritag
https://cohost.org/arborelia/post/5052044-the-software-heritag

This is probably worth thinking about as Guix is in a similar situation
regarding publishing source code, and people potentially wanting to
change historical source code both in things Guix packages and Guix
itself.

Like Software Heritage, there's cryptographical implications for
rewriting the Git history and modifying source tarballs or nars that
contain source code.

We have 17TiB of compressed source code and built software stored for
bordeaux.guix.gnu.org now and we should probably work out how to handle
people asking for things to be removed or changed (for any and all
reasons).

It's probably worth working out our position on this in advance of
someone asking.

I would go a step further actually. Software Heritage is effectively
breaking CoC of Guix now.

Im not proposing removing all code or something obviously that connects to
Software Heritage, but there should be some social action we can take.


For example until the matter is resolved and Software Heritage implements a
process that respects trans rights Software Heritage should not be welcome
in Guix Spaces.

I did skim the articles and I did not see any details on what the technical
solution should be.  SWH, among other things, archives the repositories and
allows fetching them by commit hash.  At least as far as I know.  Since that
commit hash does contain the author field, what is the proposed solution here to
change the author name without changing the commit hash?

While I am not a huge fan of the ability to map the "fake" author name over the
real one in the UI, what other solutions do you or the article author envision?
I am genuinely curious what you think can be done here.


I think you are arguing for something else than what I wrote? I didn't 
say about technical solutions and that's up to Software Heritage to 
figure it out.


I did say that there should be social consequences since Software 
Heritage is breaking CoC here.


And by breaking CoC I mean that Software Heritage seems to have a 
complete lack of empathy towards trans people.



Regarding what Guix could do personally the answer is clear: People are 
more important than machines and code.


So we should find a way that trans people feel safe in Guix.


MSavoritias


Have a nice day,
Tomas Volf